This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Backtrace prints wrong argument value
- From: Daniel Jacobowitz <drow at false dot org>
- To: Luis Machado <luisgpm at linux dot vnet dot ibm dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 25 Apr 2007 15:13:04 -0400
- Subject: Re: [patch] Backtrace prints wrong argument value
- References: <1177527233.12599.42.camel@localhost>
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