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

[Camm Maguire]

That would be so great -- thanks!

Matt Kaufmann <address@hidden> writes:

> 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
>
>
>

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