[Bug tools/25793] New: eu-readelf -w dumps incomplete even if debuginfod available

[Bug tools/25793] New: eu-readelf -w dumps incomplete even if debuginfod available

[fche at redhat dot com]

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

            Bug ID: 25793
           Summary: eu-readelf -w dumps incomplete even if debuginfod
                    available
           Product: elfutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tools
          Assignee: unassigned at sourceware dot org
          Reporter: fche at redhat dot com
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

0.179 eu-readelf -w /bin/ls  on fedora31 x86-64 gladly produces a disassembly
of the .eh_frame* content of the stripped binary.  However, it is
unable/unwilling to download debuginfo to fill in for example 'eu-readelf
-winfo' data.

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

[Bug tools/25793] eu-readelf -w dumps incomplete even if debuginfod available

[mark at klomp dot org]

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

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> ---
(In reply to Frank Ch. Eigler from comment #0)
> 0.179 eu-readelf -w /bin/ls  on fedora31 x86-64 gladly produces a
> disassembly of the .eh_frame* content of the stripped binary.  However, it
> is unable/unwilling to download debuginfo to fill in for example 'eu-readelf
> -winfo' data.

That is by design. [eu-]readelf just shows the data of the given ELF file. That
is why .eh_frame is dumped, but .debug_frame isn't (if it isn't available as
separate .debug file).

(Note that -winfo doesn't work with eu-readelf:

I think it would be a surprising change if [eu-]readelf would now by default
start looking up auxiliary files to dump data from. But maybe it could do this
in a special mode. There is some precedent to do that with an extra mode, with
--debug-dump=info+ which does lookup split-DWARF (--debug-dump=info does not).

    readelf: print split CUs when given --debug-dump=info+

    To show the difference between "regular" CUs and split CUs print
    offsets and references between { and } instead of [ and ].

    When --debug-dump=info+ is given (implied by -w) instead of
    --debug-dump=info any skeleton unit will be immediately followed
    by the corresponding split compile unit (from the .dwo file).

Maybe we could extend the + notation to other sections which could be looked up
through some extension/auxiliary lookup mechanism from the main file?

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

[Bug tools/25793] eu-readelf -w dumps incomplete even if debuginfod available

[fche at redhat dot com]

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

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
Is there another elfutils tool that would casually pretty-print dwarf related
to a stripped binary?  (binutils objdump --dwarf=follow-links does, but IMHO
that's too verbose.)

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

[Bug tools/25793] eu-readelf -w dumps incomplete even if debuginfod available

[mark at klomp dot org]

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

--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
We could maybe add something like --dwarf=follow-links to eu-readelf. But the
DWARF information dumping is already somewhat different from the rest of
eu-readelf. The basic idea of eu-readelf is that you can dump headers, segments
and sections data.  This is somewhat lower level than what you are usually
after when using DWARF. If you look at how eu-readelf dumps various .debug
sections you'll see that it really just dumps the data, and doesn't use libdw
at all. There are sometimes two ways to dump the section data
(--debug-dump=line and --debug-dump=decodedline), one which dumps the "raw"
data and one which uses libdw to decode the data first. So maybe we really need
a new tool to dump "decoded" DWARF, which isn't concerned with how the DWARF
data is precisely encoded, but just shows the information. For such a tool
(eu-dwarfdump ?) it would make perfect sense to follow, search and download
extra files when necessary.

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

[Bug tools/25793] eu-readelf -w dumps incomplete even if debuginfod available

[woodard at redhat dot com]

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

Ben Woodard <woodard at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |woodard at redhat dot com

--- Comment #4 from Ben Woodard <woodard at redhat dot com> ---
I think that keeping the default the same is fine but I think we should add an
option to make it possible like the suggested "--dwarf=follow-links" and change
the error to: "eu-readelf: cannot get debug context descriptor: No DWARF
information found. Try: —dwarf=follow-links"

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

[Bug tools/25793] eu-readelf -w dumps incomplete even if debuginfod available

[woodard at redhat dot com]

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

--- Comment #5 from Ben Woodard <woodard at redhat dot com> ---
(In reply to Mark Wielaard from comment #3)
> We could maybe add something like --dwarf=follow-links to eu-readelf. But
> the DWARF information dumping is already somewhat different from the rest of
> eu-readelf. The basic idea of eu-readelf is that you can dump headers,
> segments and sections data.  This is somewhat lower level than what you are
> usually after when using DWARF. If you look at how eu-readelf dumps various
> .debug sections you'll see that it really just dumps the data, and doesn't
> use libdw at all. There are sometimes two ways to dump the section data
> (--debug-dump=line and --debug-dump=decodedline), one which dumps the "raw"
> data and one which uses libdw to decode the data first. So maybe we really
> need a new tool to dump "decoded" DWARF, which isn't concerned with how the
> DWARF data is precisely encoded, but just shows the information. For such a
> tool (eu-dwarfdump ?) it would make perfect sense to follow, search and
> download extra files when necessary.

I really think that you need to reconsider this position. Take for example this
situation. I'm trying to diagnose a problem with boost's DWARF that was
reported to me by a dyninst developer. 

I want to:
[ben@Mustang dwqual]$ export DEBUGINFOD_URLS=https://debuginfod.elfutils.org/
[ben@Mustang dwqual]$ export DEBUGINFOD_PROGRESS=1
[ben@Mustang dwqual]$ eu-readelf --debug-dump=loc
/lib64/libboost_system.so.1.69.0
eu-readelf: cannot get debug context descriptor: No DWARF information found
[ben@Mustang dwqual]$ rpm -qf  /lib64/libboost_system.so.1.69.0
boost-system-1.69.0-18.fc32.x86_64

This could be a really a helpful debugging tool. We don't have to go digging
around for the right debuginfo RPM for the distribution since it looks it up by
buildid. I can just point eu-readelf and print out the DWARF for that binary
which would work if we didn't do split dwarf. However, it doesn't work because
we don't have a follow links function. This unnecessarily makes something that
would be very useful, not useful simply because of ideological purity.

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

[Bug tools/25793] eu-readelf -w dumps incomplete even if debuginfod available

[mark at klomp dot org]

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

--- Comment #6 from Mark Wielaard <mark at klomp dot org> ---
I am not against adding something like --debug-dump=follow-links as binutils
does (although binutils readelf even requires it for things like showing e.g.
alt indirect string attributes, which eu-readelf already does automatically).
But I don't think it is a natural fit for readelf, which basically is a data
dumping tool, not something that interprets the data encoding. However as long
as we don't have such a tool (eu-dwarfdump) we could try to fit it in.

Note however that in almost all cases elfutils readelf already "follows links"
unlike binutils, where --dwarf=follow-links is required, for showing alt-file
contents, or with --debug-dump=info+ (which is the default with --debug-dump,
unless =info [without +] is given), for following split-dwarf, dwo, CU
skeletons.

So what this request really is about, is following .gnu_debuglink and/or
build-id .debug searching (including adding debuginfod support).

One question (to show why this isn't completely natural/simple), what do you
expect for something like an DW_TAG_imported_unit (which can be "local" or
through an "alt" link). Should that actually "import" and show that unit in
place? And if so, should we show DW_TAG_partial_units separately (as we do
now), or only if they are actually used/imported to make them "whole"?

The above question is why I feel a new tool like eu-dwarfdump might be a better
"solution". Although we can certainly just make up ad-hoc answers if we add
this "follow-links" support to eu-readelf (but they will feel a little
unnatural imho.)

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