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

["mark at klomp dot org" <sourceware-bugzilla@sourceware.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.