Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Apr 25, 2007 at 03:53:53PM -0300, Luis Machado wrote:
> If we call a backtrace on GDB, that's what we have:
> 
> #0 - start_sequence (x=<value optimized out>, y=0xfffff9b1b34)
> #1 - gen_movsd (operand0=0xdeadbeef, operand1=0xfffff9b1b34)
> 
> Notice that on frame #1, "operand0" has a "0xdeadbeef" value, which
> happens to be the return value from the "start_sequence" function from
> frame #0. This is clearly incorrect.

What is the corresponding code and debug info?

I guess you have debugging information which says that operand0 is
valid on the call instruction and invalid after it.

> What is causing this incorrect value to be printed on frame levels above
> 0 is an adjustment to the PC on the "frame_unwind_address_in_block"
> function. The purpose of this adjustment to PC is to make it point to
> the branch instruction rather than the instruction right after the
> branch instruction ( this is achieved with a --pc decrement).

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

A valid location list for func1 could say that arg1 is valid
in r20 during the call to abort; the -1 puts us on the call, instead
of after it, in the unrelated func2.

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.

-- 
Daniel Jacobowitz
CodeSourcery