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

On Mon, 22 Sep 2014 21:06:30 +0200, Eli Zaretskii wrote:
> Are you saying that whenever GDB can successfully interpret this
> information and extract a value, it simply shows that value?

Yes.


> 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).
+
> We should say explicitly that GDB is unable to decypher the data,
> otherwise what we show the user looks like a teaser.

I find the current behavior the right one myself.  There is "info addr"
exactly for the cases of debugging GDB/GCC and/or disassembling inferior code
trying to extract as much information from the crashed state as possible.
Sure feel free to propose any UI changes for GDB.

Maybe "set debug entry-values" could be placed under more user
friendly "info ..." command but then its output would have to be improved from
the current set of scattered debug messages to something more formatted.


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

There is no reduction of reported info just to save some GDB computations.
GDB reports all it can.

In general lacking debug info is usually GCC's defect and not GDB's.


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

I use "readelf -wi" myself, this is equivalent to "objdump -Wi" for non-ELF
DWARF files.  There is also "eu-readelf -winfo" with slightly different output
formatting.


Jan


      reply	other threads:[~2014-09-22 19:21 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
2014-09-22 19:21           ` Jan Kratochvil [this message]

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=20140922192044.GA25256@host2.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --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