Re: Really weird things happening in Guile/GDB

[Mikael Djurfeldt]

Jim Blandy <address@hidden> writes:

> That does look strange.
> 
> Does the misbehavior happen only when running under GDB?

No.  It happened when running normally as well.

> That is, is GDB affecting the behavior of the program?  (This isn't
> clear from your message.)

I think the reason why I started using GDB was that such a lockup
occured during normal execution.  It could have been due to another
thing I was debugging, though.  Now I can't reproduce the hang outside
GDB.

But, yes, it happens under GDB, and, now at least, only under GDB.

> For this kind of stuff, I generally say `display/i $pc' and then stepi
> through the code to see where things get strange.

Oops, I had forgotten that you can do that in GDB...  :)

> >     xorl %edx,%edx
> >     movl %eax,-8(%ebp)
> >     movl %edx,-4(%ebp)
> >     fildll -8(%ebp)
> 
> These are supposed to push that value onto the top of the
> floating-point stack.  Have you done an `info float' (or whatever that
> dumb command is) to check that the value on the FP stack is correct?

It seems like it's the fildll which doesn't work:

1: x/i $eip  0x4004b2f5 <gc_end_stats+93>:      fildll 0xfffffff8(%ebp)
(gdb) p $ebp
$15 = (void *) 0xbffff67c
(gdb) x 0xbffff674
0xbffff674:     0x00003a4b
(gdb) x
0xbffff678:     0x00000000
(gdb) i fl
  R7: Empty   0x3fff8000000000000000
  R6: Empty   0x3fff8000000000000000
  R5: Empty   0x00000000000000000000
  R4: Empty   0x3ffe8000000000000000
  R3: Empty   0x00000000000000000000
  R2: Empty   0x3ff8b6a3250000000000
  R1: Empty   0x4002d000000000000000
=>R0: Empty   0x3ffed8d8d8d8d8d8d800

Status Word:         0x0061   IE             PE        SF              
                       TOP: 0
Control Word:        0x037f   IM DM ZM OM UM PM
                       PC: Extended Precision (64-bits)
                       RC: Round to nearest
Tag Word:            0xffff
Instruction Pointer: 0x23:0x40062b62
Operand Pointer:     0x2b:0x080981b0
Opcode:              0xdd58
(gdb) stepi
1: x/i $eip  0x4004b2f8 <gc_end_stats+96>:      mov    0x115c(%ebx),%ecx
(gdb) i fl
=>R7: Special 0xffffc000000000000000 Real Indefinite (QNaN)
  R6: Valid   0x3fff8000000000000000 +1                         
  R5: Empty   0x00000000000000000000
  R4: Empty   0x3ffe8000000000000000
  R3: Empty   0x00000000000000000000
  R2: Empty   0x3ff8b6a3250000000000
  R1: Empty   0x4002d000000000000000
  R0: Empty   0x3ffed8d8d8d8d8d8d800

Status Word:         0x3a61   IE             PE        SF      C1      
                       TOP: 7
Control Word:        0x037f   IM DM ZM OM UM PM
                       PC: Extended Precision (64-bits)
                       RC: Round to nearest
Tag Word:            0x8fff
Instruction Pointer: 0x23:0x4004b2f5
Operand Pointer:     0x2b:0xbffff674
Opcode:              0xdf6d
(gdb) 

> >     fstpl (%ecx)
> 
> That last instruction does the store back to scm_gc_cells_marked_acc.
> Is the FP TOS still correct before this insn?  Are the variable's
> contents correct after that store?

No.  That store stores the NAN which you see above into the variable.

> I assume they're not --- that should be where your watchpoint
> triggered.

Exactly.

> If the value on the FP TOS is correct, but the value stored in memory
> is not, then I wonder whether that instruction is being assembled
> correctly.  Can you do an x/8b $pc or whatever and check its bits
> against the Intel manual?

The fildll is assembled as 0xdf 6d f8, which seems to be wrong
according to the instruction manual.  6d refers to %edi instead of
%ebp which would be assembled as 6e.  However, the same type of error
(wrong register code) is present in the instructions which load the
operand onto the stack:

  movl %eax,-8(%ebp) : 89 45 f8  (should be 89 46 f8)

so I guess this can't be the reason for the bug.

BTW, why this difference between the intel manual and GCC/GDB???

Best,
Mikael