Re: Variable "foo" is not available

[Daniel Jacobowitz <drow@false.org>]

On Sat, Apr 02, 2005 at 09:13:06PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 2 Apr 2005 09:26:40 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
> > 
> > > The compiler was GCC in this case.  Is this a GCC bug?  I cannot
> > > imagine how we would be able to explain the fact that _every_ frame in
> > > the backtrace has this message about some of the function parameters,
> > > other than by either a GCC bug or a GDB bug.
> > 
> > Not every frame did.  Most of the frames did, but they only represent a
> > tiny handful of different functions.
> 
> 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.

> Moreover, Rainer says that he never saw such messages before in
> debugging Emacs, even though a typical Emacs backtrace always shows
> many invocations of these very functions (they are basic primitives of
> the Lisp interpreter, and Emacs runs Lisp code most of the time).

I would assume he's using a newer compiler than he used to.

> > > In any case, it is rather unhelpful for the compiler to behave that
> > > way, since it means debugging optimized programs, once a flagship of
> > > GCC features wrt other compilers, is now very hard or even
> > > impractical.  If this is intended behavior, I'd say it's a bad
> > > misfeature.
> > 
> > This is not a change in compiler behavior, in any way.  These are the
> > cases which would have printed garbage using any previous GCC release.
> > Backtraces for optimized code have always been unreliable.
> > 
> > GCC does not take debugability into account at -O2 where it would
> > compromise any performance optimization; that's what -O2 asked for.
> 
> It sounds like we were using 2 different compilers.  My experience
> with GCC, based on many years, is that -O2 optimized code can be
> debugged quite well, as soon as you get accustomed to the execution
> thread jumping back and forth due to code rearrangements.  In any
> real-life program with good code quality, the fraction of cases where
> a variable gets optimized away is very small.

This definitely has not been my experience since the beginning of the
3.x series; it was more true in the 2.x series, when GCC's optimizers
were much weaker.

As I said, it is a design goal for GCC to optimize efficiently
regardless of debugability when you ask for optimization.  It's gotten
better at that over the years.  Dwarf supports various sophisticated
mechanisms for debugging optimized code; GDB supports almost none of
them.

It's easy to not notice the problem with earlier versions of GCC. On
non-DWARF targets or old versions, the variables will appear to be
available - even if their correct values no longer exist in memory.

-- 
Daniel Jacobowitz
CodeSourcery, LLC