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
