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
