[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: Mac OS X
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: Mac OS X |
Date: |
Wed, 23 Jun 2010 16:29:32 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
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 <address@hidden> 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 <address@hidden> writes:
>>
>>
>>> The server is rebooted.
>>>
>>> Camm Maguire wrote:
>>>
>>>> Greetings!
>>>>
>>>> Tim Daly <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ssh address@hidden (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 address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- [Gcl-devel] Re: [Axiom-developer] Axiom May 2010 release, Camm Maguire, 2010/06/01
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- [Gcl-devel] Mac OS X, Camm Maguire, 2010/06/09
- Message not available
- Message not available
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/15
- Message not available
- Message not available
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/15
- Message not available
- Message not available
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/16
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/16
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/16
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/17
- Message not available
- [Gcl-devel] Re: Mac OS X,
Camm Maguire <=
- Re: [Gcl-devel] Re: Mac OS X, Matt Kaufmann, 2010/06/23
- Re: [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/23
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- [Gcl-devel] gcl on intel mac, Camm Maguire, 2010/06/29
- Message not available
- [Gcl-devel] Re: gcl on intel mac, Camm Maguire, 2010/06/30
- [Gcl-devel] Re: gcl on intel mac, Matt Kaufmann, 2010/06/30