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.
