This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Variable "foo" is not available
On Sat, Apr 02, 2005 at 12:45:21PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 1 Apr 2005 12:19:47 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> >
> > It means, literally, that the value is not available. The compiler has
> > not saved it in somewhere that is still accessible, or has not told GDB
> > properly where it was saved.
>
> 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.
> > There's always a chance that it's a GDB bug, of course.
>
> Can you suggest a way for Rainer to see if this a GDB bug? For
> example, could he somehow use readelf or similar tools to give some
> information that would help us determine whether this is a GDB bug?
You can use readelf to work it out. However, it requires passing
familiarity with the DWARF specification. The GDB code for handling
location lists is really not especially complicated; I don't expect
problems in it.
> 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.
> I also find the string we print in this case too long. (You say that
> in current CVS the output is a little nicer, but I don't see any
> changes in CVS's dwarf2loc.c, which prints this, compared with GDB
> 6.1; could you state in more detail which change you had in mind?)
Only loclist_tracepoint_var_ref prints this message any more, assuming
you are looking at a current version of the file.
2005-02-28 Daniel Jacobowitz <dan@codesourcery.com>
* dwarf2loc.c (loclist_read_variable): Set optimized_out
instead of reporting an error.
* valprint.c (value_check_printable): New function.
(common_val_print): New function. Use value_check_printable.
(value_print): Use value_check_printable.
* value.h (common_val_print): Add prototype.
...
--
Daniel Jacobowitz
CodeSourcery, LLC