[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Mac OS X
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Mac OS X |
Date: |
Wed, 09 Jun 2010 13:40:53 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
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>
0x00006423 <my_malloc+139>: mov %eax,%edx
0x00006425 <my_malloc+141>: lea 0x233caf(%ebx),%eax
0x0000642b <my_malloc+147>: mov (%eax),%eax
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
0x00006439 <my_malloc+161>: mov 0x8(%ebp),%eax
0x0000643c <my_malloc+164>: mov %eax,(%esp)
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 <=
- 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, 2010/06/23
- 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