Re: Variable "foo" is not available

["Eli Zaretskii" <eliz@gnu.org>]

> 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.

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).

> > 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.

> Only loclist_tracepoint_var_ref prints this message any more, assuming
> you are looking at a current version of the file.

Ah, okay.  I looked at the remaining string and assumed that this is
what Rainer sees.  Sorry.