Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: yao@codesourcery.com, gdb@sourceware.org
Subject: Re: Complex DWARF expressions
Date: Mon, 22 Sep 2014 19:06:00 -0000	[thread overview]
Message-ID: <838ulbxyo9.fsf@gnu.org> (raw)
In-Reply-To: <20140922184412.GA23523@host2.jankratochvil.net>

> Date: Mon, 22 Sep 2014 20:44:12 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: yao@codesourcery.com, gdb@sourceware.org
> 
> On Mon, 22 Sep 2014 20:21:14 +0200, Eli Zaretskii wrote:
> > Why can't GDB apply all this, and show a value for a given PC?
> 
> There is some reason why GDB could not determine it, this is very normal
> situation.  It would be really great if GDB could always display all values
> for -O2 -g code but that can never be possible (without reducing runtime code
> peformance and size).

Are you saying that whenever GDB can successfully interpret this
information and extract a value, it simply shows that value?  If so, I
think we should add to the DWARF gobbledygook a note to the effect
that GDB wasn't able to glean the value from that info, and maybe even
say why (like what info was missing to interpret that).

If the computation is expensive, we could have an option to enable it.
There are situations in debugging when you'd kill to know the value of
some key variable, I'm sure you know this.

And btw, how did you get the information you showed, like this:

>  <8><1663ca>: Abbrev Number: 24 (DW_TAG_GNU_call_site)
>     <1663cb>   DW_AT_low_pc      : 0x814d44f
>     <1663cf>   DW_AT_abstract_origin: <0x15e7bc>
>  <9><1663d8>: Abbrev Number: 3 (DW_TAG_GNU_call_site_parameter)
>     <1663d9>   DW_AT_location    : 1 byte block: 52     (DW_OP_reg2 (edx))
>     <1663db>   DW_AT_GNU_call_site_value: 1 byte block: 30      (DW_OP_lit0)

Can GDB show it (and if so, by which command), or is this from objdump
or some such?

> For example the call site may not have matching DW_AT_GNU_call_site_value
> because the value is just no longer computable at the caller frame from any
> data at that point of execution.  Entry values improved the number of cases
> where the value is retrievable but it is still far from 100% retrievability.

We should say explicitly that GDB is unable to decypher the data,
otherwise what we show the user looks like a teaser.

> One needs to use -O0 -g to get the values in 100% of cases.

When I'm debugging a crash of an optimized binary, and don't yet have
a recipe to reproduce the crash, compiling without optimizations is
not a useful option.

Thanks.


  reply	other threads:[~2014-09-22 19:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-21 19:33 Eli Zaretskii
2014-09-22  6:03 ` Yao Qi
2014-09-22  6:17   ` Jan Kratochvil
2014-09-22 18:21     ` Eli Zaretskii
2014-09-22 18:44       ` Jan Kratochvil
2014-09-22 19:06         ` Eli Zaretskii [this message]
2014-09-22 19:21           ` Jan Kratochvil

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=838ulbxyo9.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=yao@codesourcery.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