Re: [patch] Backtrace prints wrong argument value

[Luis Machado <luisgpm@linux.vnet.ibm.com>]

Hi,

Just bringing back the discussion about this little issue on backtrace.

This same behaviour seems to apply to x86 as well, but instead of
showing an incorrect value just on "operand0", it shows them incorrectly
for both "operando0" and "operand1".

That would look like this:

gen_movsd (operand0=0xdeadbeef, operand1=0xdeadbeef)

> > What is the corresponding code and debug info?
> 
> This is the complete GDB log:
> 
> (gdb) start
> Breakpoint 1 at 0x10000600: file pr28136.c, line 18.
> Starting program: /home/luis/binaries/pr28136-64
> main () at pr.c:18
> 18        x = 13;
> (gdb) s
> During symbol reading, incomplete CFI data; unspecified registers (e.g.,
> r0) at 0x10000600.
> 19        y = 14;
> (gdb) s
> 20        return (int)gen_movsd (&x, &y);
> (gdb)
> gen_movsd (operand0=0xfffff80cb20, operand1=0xfffff80cb24) at pr.c:11
> 11              return *start_sequence(operand0, operand1);
> (gdb)
> 0x00000000100005b0 in start_sequence (x=<value optimized out>,
> y=0xfffff80cb24) at pr.c:6
> 6       };
> (gdb) bt
> #0  0x00000000100005b0 in start_sequence (x=<value optimized out>,
> y=0xfffff80cb24) at pr.c:6
> #1  0x00000000100005d0 in gen_movsd (operand0=0xdeadbeef,
> operand1=0xfffff80cb24) at pr.c:11
> #2  0x0000000010000618 in main () at pr.c:20
> (gdb) s
> gen_movsd (operand0=<value optimized out>, operand1=<value optimized
> out>) at pr.c:12
> 12      }
> (gdb)
> 
> > I guess you have debugging information which says that operand0 is
> > valid on the call instruction and invalid after it.
> 
> That's the case, "operand0" is valid from low to high where:
> low:  0x100005c0
> high: 0x100005d0
> 
> After that range (including 0x100005d0), "operand0" is invalid, just
> like "operand1".
> 
> The same happens with "X" from "start_sequence". X is just valid from
> 0x100005a0 to 0x100005a4.
> 
> > You've partly misunderstood the purpose of the decrement.  We never
> > look at the branch instruction; it's to make sure that the PC points
> > to the same function as the call instruction, in the case of a
> > function that ends in a call to abort.  Having it point to the middle
> > of an instruction is perfectly fine.
> > 
> > Consider this code:
> > 
> > func1:
> > 	copy arg1 to r20
> > 	call abort
> > 
> > func2:
> > 	copy arg2 to r3
> > 	call func1
> > 	return
> > 
> 
> So the whole purpose of the decrement is to maintain the PC inside the
> code block of the function that has called a more inner frame function.
> It makes sense now. Thanks.
> 
> > I believe this is considered a known weakness of the DWARF
> > representation, which does not represent state before an instruction
> > separately from state after it.  The debug info does not tell us
> > whether the location is valid in the middle of the call.
> 
> DWARF does seem to lack precision in this case.
> 
> In order to keep values consistent throughout all the program's
> execution, how would we manage that? It might confuse people debugging
> their binaries and facing a different value on backtrace than it is
> expected.
> 
> It looks like getting the PC back to its original value (after the
> function call) would be a good thing since it's desirable that GDB
> displays no value at all instead of incorrect ones.

Does setting the PC back to its original value during the search for the
correct location expression sound reasonable?

Best Regards,
Luis