[Gcl-devel] Re: 2.7.0

[Camm Maguire]

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