This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Variable "foo" is not available
> 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.