Re: Really weird things happening in Guile/GDB

[Jim Blandy]

That does look strange.

Does the misbehavior happen only when running under GDB?  That is, is
GDB affecting the behavior of the program?  (This isn't clear from
your message.)

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

Here are the instructions for the misbehaving line:

>       movl address@hidden(%ebx),%esi
>       movl address@hidden(%ebx),%edi
>       movl (%edi),%eax
>       movl (%esi),%edx
>       subl %eax,%edx
>       movl %edx,%eax

Those ought to compute `scm_gc_cells_swept - scm_gc_cells_collected',
and leave the result in %eax.  Have you stepi'd to after that
last `movl' and then said `print $eax' to make sure it's correct?

>       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?

>       movl address@hidden(%ebx),%ecx
>       faddl (%ecx)

These are supposed to add the value of scm_gc_cells_marked_acc to the
top of the FP stack, leaving the result on the top of the FP stack.
Have you checked again here that the value on the top of the FP stack
is correct?

> .stabn 68,0,885,.LM140-gc_end_stats
> .LM140:
>       addl $-12,%esp
>       leal address@hidden(%ebx),%eax
> .stabn 68,0,884,.LM141-gc_end_stats
> .LM141:
>       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?

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

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?