That would be so great -- thanks! Matt Kaufmann <kaufm...@cs.utexas.edu> 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 <c...@maguirefamily.org> > Date: Wed, 23 Jun 2010 16:29:32 -0400 > X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) > Cc: gcl-devel@gnu.org > Sender: gcl-devel-bounces+kaufmann=cs.utexas....@gnu.org > 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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> writes: > >> > >> > >>> The server is rebooted. > >>> > >>> Camm Maguire wrote: > >>> > >>>> Greetings! > >>>> > >>>> Tim Daly <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> writes: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> ssh c...@axiom-developer.com (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 > c...@maguirefamily.org > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > > _______________________________________________ > Gcl-devel mailing list > Gcl-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/gcl-devel > > > -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
