[Gcl-devel] Re: Mac OS X

[Camm Maguire]

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