[Bug tools/22250] New: readelf should support --dwarf-start and --dwarf-depth

[Bug tools/22250] New: readelf should support --dwarf-start and --dwarf-depth

[tromey at sourceware dot org]

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

            Bug ID: 22250
           Summary: readelf should support --dwarf-start and --dwarf-depth
           Product: elfutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tools
          Assignee: unassigned at sourceware dot org
          Reporter: tromey at sourceware dot org
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

objdump supports --dwarf-start and --dwarf-depth options.
--dwarf-start specifies the DIE at which to begin dumping.
--dwarf-depth specifies how many levels down to print; if
there are more levels it just prints "...", like:

 <0><2174>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <2175>   DW_AT_producer    : (indirect string, offset: 0x0): clang LLVM
(rustc version 1.20.0 (f3d6973f4 2017-08-27))
    <2179>   DW_AT_language    : 28     (Unknown: 1c)
    <217b>   DW_AT_name        : (indirect string, offset: 0x1621):
/checkout/src/libstd/lib.rs
    <217f>   DW_AT_stmt_list   : 0x9f2
    <2183>   DW_AT_comp_dir    : (indirect string, offset: 0x163d):
/checkout/obj
    <2187>   DW_AT_low_pc      : 0x0
    <218f>   DW_AT_ranges      : 0x2be80
 <1><2193>: ...


These are handy for investigating large files with dwarf-mode that
is in binutils.

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

[Bug tools/22250] readelf should support --dwarf-start and --dwarf-depth

[mark at klomp dot org]

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.

[Bug tools/22250] readelf should support --dwarf-start and --dwarf-depth

[mark at klomp dot org]

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

--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
Addition. "the special value 0 for n" also restores printing the CU headers.

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

[Bug tools/22250] readelf should support --dwarf-start and --dwarf-depth

[mark at klomp dot org]

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

--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
Another addition "depth" starts counting from zero. Zero usually is the first
DIE (compilation_unit or partial_unit). Specifying --dwarf-depth=0 will only
print the Compilation Unit headers, followed by a blank line and no ...
markers. Unless --dwarf-depth is given with a non-zero argument, then only a
blank line is printed.

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

[Bug tools/22250] readelf should support --dwarf-start and --dwarf-depth

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Mark Wielaard from comment #1)

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

I implemented this stuff in objdump to support browsing DWARF in Emacs.
The Emacs mode dumps the "outline" of the DWARF into a buffer, then
you can click on a '...' to get more data there.  That explains why
header suppression is done...

However lately I wanted to use this with eu-readelf to track down that
bad DWARF bug: https://github.com/rust-lang/rust/issues/44412
In that case I wouldn't care so much about the headers.

But really it would be nice to have it all so that I could port the
Emacs mode to use eu-readelf.

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