Greetings! Robert Boyer <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> ; 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 [EMAIL PROTECTED] ========================================================================== "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