Re: Variable "foo" is not available

[Daniel Jacobowitz <drow@false.org>]

On Sat, Apr 02, 2005 at 11:54:08PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 2 Apr 2005 13:40:23 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
> > 
> > > 9 different functions were reported with such arguments.  IMHO, that's
> > > too many for a rare situation.
> > 
> > I didn't say it was a rare situation.
> 
> If it isn't rare, we should do something about it, I think.
> 
> > It's easy to not notice the problem with earlier versions of GCC.
> 
> I'm using GCC 3.x since the year 2001, and the DWARF 2 debug info as
> the default since more than a year ago.  I think this is long enough
> not to dismiss my experience.
> 
> Anyway, I don't really understand what is your intent.  Are you saying
> that this is what we should expect from optimized code in GDB, and
> that nothing should or could be done about it?

What are you suggesting we do about it?  There are only two options:
make the argument remain available, which carries a performance
penalty, or politely inform the user that it is unavailable.  The user
asked for no performance penalties.

I'm not trying to dismiss your experience; but I've worked on this code
in the compiler, and it's just not designed to do what you're
expecting.

> > On non-DWARF targets or old versions, the variables will appear to
> > be available - even if their correct values no longer exist in
> > memory.
> 
> We are talking about function call arguments here, not just about any
> local variables.  Can you tell what compiler optimizations could cause
> what Reiner reported: that the first argument is available to GDB, but
> the second is not?

Very easily.  Suppose you have two incoming arguments in registers; GCC
will do this automatically for static functions even on i386, which
normally uses a stack convention.  The first is used after a function
call, so it is preserved by saving it to the stack.  The second is not
used after the function call, so the compiler has no reason to allocate
a save slot for it, and no reason to store it to memory before the
function call.

With stack-based argument passing, GCC may be claiming an argument is
unavailable when the function's local copy is dead, when a copy still
exists on the stack somewhere.  I don't know if it will do that or not.
GDB can not assume that the argument is available in the incoming stack
slot, since it could be reused for other data.

-- 
Daniel Jacobowitz
CodeSourcery, LLC