Re: [Gcl-devel] Re: Mac OS X

[Matt Kaufmann]

Hi, Camm --

In case you don't need that Mac to be at Tim's site:

On my desktop I have a ppc mac running Mac OS 10.4.11.  I can give you
an account when I'm at work tomorrow, if you like.

-- Matt
   From: Camm Maguire <address@hidden>
   Date: Wed, 23 Jun 2010 16:29:32 -0400
   X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2)
   Cc: address@hidden
   Sender: address@hidden
   X-SpamAssassin-Status: No, hits=-0.7 required=5.0
   X-UTCS-Spam-Status: No, hits=-256 required=165

   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

   _______________________________________________
   Gcl-devel mailing list
   address@hidden
   http://lists.gnu.org/mailman/listinfo/gcl-devel