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