[Gcl-devel] Re: Mac OS X

[Camm Maguire]

Greetings!  You don't happen to have access to an older ppc mac os x
box so I can compare the older working code, do you?

Take care,

Tim Daly <address@hidden> writes:

> fixed
>
> Camm Maguire wrote:
>> Greetings, and thanks!
>>
>> ssh axiom-developer.com
>> ssh: connect to host axiom-developer.com port 22: Connection refused
>>
>>
>> Tim Daly <address@hidden> writes:
>>
>>   
>>> The server is rebooted.
>>>
>>> Camm Maguire wrote:
>>>     
>>>> Greetings!
>>>>
>>>> Tim Daly <address@hidden> writes:
>>>>
>>>>         
>>>>> Generally I encounter these kinds of errors due to SELinux.
>>>>> I disable SELinux exec-shield and randomize loading everywhere.
>>>>> They are pointless bandaids. However, on OS X I don't see them
>>>>> installed anywhere.
>>>>>
>>>>> There is a check for "use secure virtual memory" in security
>>>>>             
>>>>                         ^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>
>>>> This sounds promising.  I'm ready for a reboot whenever you are.  If
>>>> you can drop me a note when its back up that would be great.
>>>>
>>>> Take care,
>>>>
>>>>         
>>>>> which I disabled but I'll need to reboot for it to take effect.
>>>>> I can reboot anytime but you'll have to let me know when.
>>>>>
>>>>> Camm Maguire wrote:
>>>>>             
>>>>>> Greetings!  Progess continues, but now I've run into a new (hopefully
>>>>>> final) difficulty.  GCL loads compiled .o files, marks the memory
>>>>>> PROT_READ|PROT_WRITE|PROT_EXEC, and then executes it.  Typically, the
>>>>>> memory resides in the .data segment, but here there is a static
>>>>>> separate heap allocated with vm_allocate.  In any case, mprotect is
>>>>>> returning "permision denied"
>>>>>>
>>>>>>      [EACCES]           The requested protection conflicts with the 
>>>>>> access
>>>>>>                         permissions of the process on the specified 
>>>>>> address
>>>>>>                         range.
>>>>>>
>>>>>> Something in the kernel is setup to forbid execution (most likely) of
>>>>>> vm_allocate'd memory.  Omiting the call gives a kernel access denied
>>>>>> error on jumping to the new address. (On ppc mac os x, there was no
>>>>>> mprotect required, just some (ppc specific) assembly to clear the
>>>>>> instruction cache.  This mprotect setup is what is used on the
>>>>>> majority of linux platforms.)
>>>>>>
>>>>>> Anyway, wondering if you new anything about your kernel security
>>>>>> settings and/or might you check your logs to get a hint toward a
>>>>>> workaround. 
>>>>>>
>>>>>> Take care,
>>>>>>
>>>>>> Tim Daly <address@hidden> writes:
>>>>>>
>>>>>>                   
>>>>>>> xcode-select -printpath shows /Developer which is where XCode lives.
>>>>>>>
>>>>>>> I am downloading the latest xcode now.
>>>>>>>
>>>>>>> Camm Maguire wrote:
>>>>>>>                         
>>>>>>>> Greetings!  I've been told gcc-4.2 is the latest for mac, but you have
>>>>>>>> 4.0 installed.  Is something called xcode installed?  macports?  Are
>>>>>>>> there any command line tools to query installed software and available
>>>>>>>> options?  Can you please install gcc 4.2?
>>>>>>>>
>>>>>>>> Take care,
>>>>>>>>
>>>>>>>> Tim Daly <address@hidden> writes:
>>>>>>>>
>>>>>>>>                                 
>>>>>>>>> I show some speculation below but perhaps rewriting this
>>>>>>>>>
>>>>>>>>> malloc_list->c.c_car = alloc_simple_string(size);
>>>>>>>>>
>>>>>>>>> into
>>>>>>>>> t1 = alloc_simple_string(size);
>>>>>>>>> t2 = malloc_list->c
>>>>>>>>> t3.c = t1
>>>>>>>>>
>>>>>>>>> or some equivalent might
>>>>>>>>> (a) not trip across the compiler bug and
>>>>>>>>> (b) give you a better clue what it does not like
>>>>>>>>>
>>>>>>>>> Camm Maguire wrote:
>>>>>>>>>                                         
>>>>>>>>>> Greetings!
>>>>>>>>>>
>>>>>>>>>> Tim Daly <address@hidden> writes:
>>>>>>>>>>
>>>>>>>>>>                                                   
>>>>>>>>>>> The MAC is back online.
>>>>>>>>>>>
>>>>>>>>>>>                                                             
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> Do you speak any assembler?  I'm failing now here:
>>>>>>>>>>
>>>>>>>>>> 0x0000641e <my_malloc+134>:  call   0x2e5b <make_cons>
>>>>>>>>>>                                                   
>>>>>>>>> this call succeeded so now we need to set up the stack for the
>>>>>>>>> alloc_simple_string call
>>>>>>>>> to do that the compiler would have to
>>>>>>>>>  (a) get the malloc_list value
>>>>>>>>>  (b) get the c struct pointer
>>>>>>>>>  (c) get the c_car pointer off of the c struct
>>>>>>>>>  (d) push the size
>>>>>>>>>  (e) call alloc_simple_string
>>>>>>>>> so I'm going to do some guessing.
>>>>>>>>>                                         
>>>>>>>>>> 0x00006423 <my_malloc+139>:  mov    %eax,%edx
>>>>>>>>>>                                                   
>>>>>>>>> Notice that the 'lea 0x233caf(%ebx)' (load effective address) is done 
>>>>>>>>> twice.
>>>>>>>>> This must be a reference to a known location since the compiler has
>>>>>>>>> inlined it.
>>>>>>>>> It is not clear what this "known location" is since I don't have the
>>>>>>>>> symbol table
>>>>>>>>> but I'm guessing it is "malloc_list"
>>>>>>>>>
>>>>>>>>> Proceeding on that assumption we load %eax with the address of 
>>>>>>>>> malloc_list
>>>>>>>>>                                         
>>>>>>>>>> 0x00006425 <my_malloc+141>:  lea    0x233caf(%ebx),%eax
>>>>>>>>>>                                                   
>>>>>>>>> We then use the contents of %eax (the address of malloc_list) to get
>>>>>>>>> the word
>>>>>>>>> it points at.... maybe malloc_list->c
>>>>>>>>>                                         
>>>>>>>>>> 0x0000642b <my_malloc+147>:  mov    (%eax),%eax                      
>>>>>>>>>>                                
>>>>>>>>> Then we try to store %edx into this location pointer? But %edx is a
>>>>>>>>> free variable here
>>>>>>>>> so I have no idea what it might contain.
>>>>>>>>>                                         
>>>>>>>>>>      0x0000642d <my_malloc+149>:     mov    %edx,(%eax)
>>>>>>>>>> <-------
>>>>>>>>>> 0x0000642f <my_malloc+151>:  lea    0x233caf(%ebx),%eax
>>>>>>>>>> 0x00006435 <my_malloc+157>:  mov    (%eax),%eax
>>>>>>>>>> 0x00006437 <my_malloc+159>:  mov    (%eax),%esi
>>>>>>>>>>                                                   
>>>>>>>>> at this point 0x8(%ebp) would be an access off the base pointer of 
>>>>>>>>> the frame
>>>>>>>>> so I'm guessing that 'size' was passed in from some prior call. %eax
>>>>>>>>> contains
>>>>>>>>> the 'size' value.
>>>>>>>>>                                         
>>>>>>>>>> 0x00006439 <my_malloc+161>:  mov    0x8(%ebp),%eax
>>>>>>>>>>                                                   
>>>>>>>>> at this point %eax must contain the address of 'size' (item d above)
>>>>>>>>>                                         
>>>>>>>>>> 0x0000643c <my_malloc+164>:  mov    %eax,(%esp)
>>>>>>>>>>                                                   
>>>>>>>>> at this point the top of stack would be pointing at the 'size' 
>>>>>>>>> argument
>>>>>>>>>                                         
>>>>>>>>>> 0x0000643f <my_malloc+167>:  call   0xa79a4 <alloc_simple_string>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> on C code
>>>>>>>>>>
>>>>>>>>>>      malloc_list = make_cons(Cnil, malloc_list);
>>>>>>>>>>
>>>>>>>>>>      malloc_list->c.c_car = alloc_simple_string(size);
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> with
>>>>>>>>>>
>>>>>>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>>>>>>>> Reason: KERN_INVALID_ADDRESS at address: 0xff17a000
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> because gcc compiled some dereferencing of this address at the above
>>>>>>>>>> instruction between the calls, presumably to set the cons to the
>>>>>>>>>> variable malloc_list.  But the address of the latter is not 
>>>>>>>>>> 0xff17a000
>>>>>>>>>> but
>>>>>>>>>>
>>>>>>>>>> p &malloc_list
>>>>>>>>>> $7 = (object *) 0x102410
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Anyway, I have no contacts with any mac people, so don't know where
>>>>>>>>>> really to turn.  First guess is a compiler bug.  Google turns up 
>>>>>>>>>> other
>>>>>>>>>> examples (different applications) with no obvious solutions.
>>>>>>>>>>
>>>>>>>>>> Take care,
>>>>>>>>>>
>>>>>>>>>>                                                   
>>>>>>>>>>> Camm Maguire wrote:
>>>>>>>>>>>                                                             
>>>>>>>>>>>> Greetings!
>>>>>>>>>>>>
>>>>>>>>>>>> Tim Daly <address@hidden> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>                                                                    
>>>>>>>>>>>>      
>>>>>>>>>>>>> Actually all of the code is gradually getting moved into a single
>>>>>>>>>>>>> file, e.g. the interpreter code will all live in bookvol5.lsp.
>>>>>>>>>>>>> I will be adding type decorations for the lisp code directly
>>>>>>>>>>>>> into the file.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm still in the process of consolidating the code. I have about
>>>>>>>>>>>>> 120 files to add. I am "tree-shaking" the code as I add it so only
>>>>>>>>>>>>> live routines are picked up. Old, dead code is never moved and 
>>>>>>>>>>>>> dropped.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am trying to create a fully literate form of Axiom so all of
>>>>>>>>>>>>> the code in the interpreter will be in book form, in volume 5.
>>>>>>>>>>>>> All of the compiler will live in volume 9.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have moved most of the system already. All of the spad code 
>>>>>>>>>>>>> lives
>>>>>>>>>>>>> in volume 10, all of the graphics (vol8) and hyperdoc (vol 7) are
>>>>>>>>>>>>> in their own books.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I want to restructure Axiom along the lines of Christian 
>>>>>>>>>>>>> Queinnac's
>>>>>>>>>>>>> Lisp In Small Pieces book. You should be able to "read" Axiom like
>>>>>>>>>>>>> a novel. That way, when I get hit by a bus, someone else has a 
>>>>>>>>>>>>> slim
>>>>>>>>>>>>> chance of maintaining and extending Axiom. Otherwise this code is
>>>>>>>>>>>>> way too complex and it will just die.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                                                                   
>>>>>>>>>>>>>                   
>>>>>>>>>>>> Needless to say, I think your efforts are just fantastic.
>>>>>>>>>>>>
>>>>>>>>>>>> Not to distract from them, but if we could get these two 
>>>>>>>>>>>> :native-reloc
>>>>>>>>>>>> patches in at the depsys and interpsys creation stages, and
>>>>>>>>>>>> (hopefully) if we could get into the testing loop a test build 
>>>>>>>>>>>> with a
>>>>>>>>>>>> gcl without :native-reloc in *features*, life, at least 
>>>>>>>>>>>> Debian/Ubuntu
>>>>>>>>>>>> life, would go ever so much more smoothly.
>>>>>>>>>>>>
>>>>>>>>>>>> These #-native-reloc branches are successfully working on alpha, 
>>>>>>>>>>>> mips,
>>>>>>>>>>>> mipsel, ia64, and hppa at
>>>>>>>>>>>>
>>>>>>>>>>>> https://buildd.debian.org/status/package.php?p=axiom
>>>>>>>>>>>>
>>>>>>>>>>>> BTW, intel mac appears to be off again.  Would it be possible to 
>>>>>>>>>>>> leave
>>>>>>>>>>>> it up and I will let you know when I've figured out a fix?  It 
>>>>>>>>>>>> could
>>>>>>>>>>>> take some time alas, as its related to gmp and not gcl proper.
>>>>>>>>>>>>
>>>>>>>>>>>> Take care,
>>>>>>>>>>>>
>>>>>>>>>>>>                                                                    
>>>>>>>>>>>>      
>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Camm Maguire wrote:
>>>>>>>>>>>>>                                                                   
>>>>>>>>>>>>>                   
>>>>>>>>>>>>>> BTW, I take it the older PASS1=t build followed by a touch of 
>>>>>>>>>>>>>> all lsp
>>>>>>>>>>>>>> and a remake to load the .fn files is no longer required for 
>>>>>>>>>>>>>> optimal
>>>>>>>>>>>>>> compilations? 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Take care,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tim Daly <address@hidden> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                                                                  
>>>>>>>>>>>>>>                                  
>>>>>>>>>>>>>>> ssh address@hidden  (note the .com, not .org)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Camm Maguire wrote:
>>>>>>>>>>>>>>>                                                                 
>>>>>>>>>>>>>>>                                                 
>>>>>>>>>>>>>>>> Greetings!  Tim, do you have a publicly accessible intel mac 
>>>>>>>>>>>>>>>> osx
>>>>>>>>>>>>>>>> machine I can use for gcl porting?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>                                                                
>>>>>>>>>>>>>>>>                                                                
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>>                                                                 
>>>>>>>>>>>>>>>                                                 
>>>>>>>>>>>>>>                                                                  
>>>>>>>>>>>>>>                                  
>>>>>>>>>>>>>                                                                   
>>>>>>>>>>>>>                   
>>>>>>>>>>>>                                                                    
>>>>>>>>>>>>      
>>>>>>>>>>>                                                             
>>>>>>>>>>                                                   
>>>>>>>>>                                         
>>>>>>>>                                 
>>>>>>>                         
>>>>>>                   
>>>>>             
>>>>         
>>>
>>>
>>>     
>>
>>   
>
>
>
>

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah