gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: Mac OS X


From: Camm Maguire
Subject: [Gcl-devel] Re: Mac OS X
Date: Wed, 16 Jun 2010 18:42:09 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]