Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
Subject: Re: Variable "foo" is not available
Date: Sat, 02 Apr 2005 14:26:00 -0000	[thread overview]
Message-ID: <20050402142639.GA27550@nevyn.them.org> (raw)
In-Reply-To: <01c53768$Blat.v2.4$d52008a0@zahav.net.il>

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


  parent reply	other threads:[~2005-04-02 14:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-01 16:40 Reiner Steib
2005-04-01 17:19 ` Daniel Jacobowitz
2005-04-02  9:49   ` Eli Zaretskii
2005-04-02 13:53     ` Reiner Steib
2005-04-02 14:27       ` Daniel Jacobowitz
2005-04-06 16:25         ` Reiner Steib
2005-04-02 14:26     ` Daniel Jacobowitz [this message]
2005-04-02 18:17       ` Eli Zaretskii
2005-04-02 18:40         ` Daniel Jacobowitz
2005-04-02 20:58           ` Eli Zaretskii
2005-04-02 21:05             ` Daniel Jacobowitz
2005-04-04  5:14               ` Eli Zaretskii
2005-04-04  6:00                 ` Mark Kettenis
2005-04-04  7:58                 ` Daniel THOMPSON
2005-04-04 19:28                   ` Eli Zaretskii
2005-04-04 13:37                 ` Daniel Jacobowitz
2005-04-04 19:35                   ` Eli Zaretskii
2005-04-04 19:41                     ` Daniel Jacobowitz
2005-04-03 18:16           ` Reiner Steib
2005-04-08 11:05       ` Eli Zaretskii
2005-04-04  9:26     ` Reiner Steib

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050402142639.GA27550@nevyn.them.org \
    --to=drow@false.org \
    --cc=Reiner.Steib@gmx.de \
    --cc=eliz@gnu.org \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox