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.
(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?
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.)
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 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"
(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.
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.)