[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: 2.7.0
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: 2.7.0 |
Date: |
25 Feb 2006 13:02:10 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
Robert Boyer <address@hidden> writes:
> I've just built a new 2.7.0, and it still has that segmentation violation.
> Here is the cvs/configure/make transcript, fwiw.
>
OK, I've looked at this a bit. Here's the scoop:
1) psetq expands to a (let ((v val)) (setq ...)) and so creates a
local variable. As the outer variable I is declared fixnum, and
the init form is (1- i), the temp variable is an integer (its
pathetic that we currently cannot catch the lion's share of cases
where this is also a fixnum, but it requires that the compiler
understand loop exit conditions, etc.) (This is the biggest reason
why 2.7.0 defines the seqind type, thish is the maximum sequence
length, as simple operations like this are still known to return
fixnum.)
2) GCL has a sophisticated mechanism to avoid memory allocations for
local bignums (i.e. they can be allocated on the stack in certain
cases). (I've yet to determine whether this is actually a
performance win or not, and it definitely makes the code more
fragile, as one must use heap rather that stack allocation if
setjmps are in force, or other such exceptions. Please see
bignum-expansion-storage if interested. Still, someone went to a
lot of work to put this in and I'm always hesitatnt to remove such
things.)
3) I have been unable to reproduce because my compiler is using a
builtin instruction to the bzero call that initializes the stack
memory (gcc 4.0.x): (cld) (I thought this was universal which is
why I wrote the C macro this way, but ...)
0x08ac64f8 <L1__EEE___foo+1079>: mov %eax,%edx
0x08ac64fa <L1__EEE___foo+1081>: mov 0xfffffff0(%ebp),%eax
0x08ac64fd <L1__EEE___foo+1084>: mov %eax,%edi
0x08ac64ff <L1__EEE___foo+1086>: cld
0x08ac6500 <L1__EEE___foo+1087>: mov %edx,%ecx
0x08ac6502 <L1__EEE___foo+1089>: mov $0x0,%al
0x08ac6504 <L1__EEE___foo+1091>: repz stos %al,%es:(%edi)
0x08ac6506 <L1__EEE___foo+1093>: mov 0xfffffff0(%ebp),%eax
4) Your segfault is caused by an attempt to call a bzero function
which apparently does not exist in the image:
p bzero
$6 = {<text variable, no debug info>} 0x83ebdb0 <bzero>
(gdb)
0x0a0ae9ff <L1+827>: lea 0xc(%esp),%eax
0x0a0aea03 <L1+831>: mov %eax,0xffffffe0(%ebp)
0x0a0aea06 <L1+834>: mov 0xffffffec(%ebp),%eax
0x0a0aea09 <L1+837>: add 0xffffffe4(%ebp),%eax
0x0a0aea0c <L1+840>: add 0xffffffe8(%ebp),%eax
0x0a0aea0f <L1+843>: mov %eax,0x4(%esp)
---Type <return> to continue, or q <return> to quit---
0x0a0aea13 <L1+847>: mov 0xffffffe0(%ebp),%eax
0x0a0aea16 <L1+850>: mov %eax,(%esp)
0x0a0aea19 <L1+853>: call 0x1847e190 ; This should be bzero's address
0x0a0aea1e <L1+858>: mov 0xffffffe0(%ebp),%eax
0x0a0aea21 <L1+861>: mov %eax,0xfffffff0(%ebp)
5) I've been unable to reproduce this on backyard using the
configuration --enable-ansi --enable-debug --disable-statsysbfd
--enable-locbfd:
0x08987ba9 <L1+837>: add 0xffffffe4(%ebp),%eax
0x08987bac <L1+840>: add 0xffffffe8(%ebp),%eax
0x08987baf <L1+843>: mov %eax,0x4(%esp)
---Type <return> to continue, or q <return> to quit---
0x08987bb3 <L1+847>: mov 0xffffffe0(%ebp),%eax
0x08987bb6 <L1+850>: mov %eax,(%esp)
0x08987bb9 <L1+853>: call 0x804ad14 <address@hidden> ; This is right
0x08987bbe <L1+858>: mov 0xffffffe0(%ebp),%eax
0x08987bc1 <L1+861>: mov %eax,0xfffffff0(%ebp)
How to proceed from here?
Take care,
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah