Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz <drow at false dot org>]

On Wed, May 16, 2007 at 02:34:00AM -0300, Luis Machado wrote:
> On Wed, 2007-04-25 at 15:13 -0400, Daniel Jacobowitz wrote:
> > 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.
> 
> Do you have anything in mind in order to better handle this situation
> instead of showing wrong values in backtrace every now and then?
> 
> >From your comment it wasn't clear if hiding possibly wrong values is
> worse than showing them sometimes.

There is simply not enough information in the debug info to handle
this correctly.  Let me give you another example:

     move var to r3
     test something
     if true, branch to Lfoo
     call abort, which clobbers r3
Lfoo:
     do something with r3

At every instruction after the move, the debug info should say that
var is in r3.  Right?  No matter which location we pick here, while
backtracing from abort, we'll print the wrong value for var and
there's no point where the debug info will say it is undefined.

If you want us to get this right using DWARF info, I believe your only
choice is to approach the DWARF working group about it.

Now, in GDB we may have other options.  We might be able to get the
list of call clobbered registers based on the ABI.  Compare with s390,
which already does this (dwarf2_frame_set_init_reg).  Does adding
this to PowerPC help your example any?

-- 
Daniel Jacobowitz
CodeSourcery