public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug tools/22250] readelf should support --dwarf-start and --dwarf-depth
Date: Thu, 05 Oct 2017 12:19:00 -0000	[thread overview]
Message-ID: <bug-22250-10460-7aPiIXuGzg@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-22250-10460@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=22250

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at klomp dot org

--- Comment #1 from Mark Wielaard <mark at klomp dot org> ---
For reference this is the binutils objectdump man page documentation for these
two options:

       --dwarf-depth=n
           Limit the dump of the ".debug_info" section to n children.  This is
           only useful with --dwarf=info.  The default is to print all DIEs;
           the special value 0 for n will also have this effect.

           With a non-zero value for n, DIEs at or deeper than n levels will
           not be printed.  The range for n is zero-based.

       --dwarf-start=n
           Print only DIEs beginning with the DIE numbered n.  This is only
           useful with --dwarf=info.

           If specified, this option will suppress printing of any header
           information and all DIEs before the DIE numbered n.  Only siblings
           and children of the specified DIE will be printed.

           This can be used in conjunction with --dwarf-depth.

You can specify "the DIE numbered n" as decimal or 0x hexadecimal. It seems it
isn't really the "number" but the first DIE starting after the given offset
from the start of the section data. Also it suppresses printing of the actual
CU headers (which would make it hard with the output format of eu-readelf to
see where a CU starts/ends). It will just continue printing DIEs till the end
of the section.

Which properties of the above are important to you?
Is the given selection mechanism of which DIEs to print the most convenient?
Is it important to suppress header printing?
Since this really is about printing something after an offset from the start of
a section, should it be extended to other debug sections?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  reply	other threads:[~2017-10-05 12:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04 16:14 [Bug tools/22250] New: " tromey at sourceware dot org
2017-10-05 12:19 ` mark at klomp dot org [this message]
2017-10-05 12:20 ` [Bug tools/22250] " mark at klomp dot org
2017-10-05 12:31 ` mark at klomp dot org
2017-10-05 16:40 ` tromey at sourceware dot org

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=bug-22250-10460-7aPiIXuGzg@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=elfutils-devel@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).