Greetings! Thanks! Status: unexec functional for one iteration only -- need to modify current emacs code which (no longer) can handle dumping of previously dumped images, which we definitely need. This worked once, and I see no reason why it cannot again. Post on emacs-devel yields no responses so far.
Original contributor aurelien has been reached and offered to help. mprotect issue has been fixed. unexec was setting maximum permissions on the data segment to prevevnt this. bfd relocation code with unaltered current binutils fails. I suspect there is a patch from aurelien's older mach-o-reloc.c file for the ppc which needs adding, regarding indirect relocations and branch islands. If attempts to port this fail, we will have to fall back on dlopen or custreloc (sfaslmacosx.c), while unpleasant, doable. BTW, axiom(and acl2/maxima/hol88 ...) can now be run on japanese sh4 processors via the Debian sh4-linux port. 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
