eliben
Wide support
Implements issue https://github.com/eliben/pyelftools/issues/405 for -W --wide support for readelf.py
I can only reiterate that I don't see the point of this feature, unless someone wants to repurpose readelf.py as a more or less drop-in replacement for GNU readelf. Which is only needful if one is parsing its output for further programmatic processing, which I can't possibly endorse, since my preferred approach would be writing your own DWARF tooling based on pyelftools.
From what I can see, autotest against readelf -W with GNU is not in the books. That's good, since attempting that would incur a ton of maintenance down the road, as it would cause twice the amount of output format discrepancies.
That said, the core library is intact. Merge away, no hard veto from me.
@sevaa makes a good point, and I'm not sure you've addressed that in the original issue, @WillDenissen. Indeed, full feature parity between readelf.py and the GNU tool is not a goal of the project - it's a huge amount of work overall and the benefit is unclear. Obviusly, readelf.py demonstrates that such a tool can be built using elftools, and I encourage others to develop it separately, if desired.
Can you please comment whether this PR improves the coverage of the elftools library itself, or whether it's primarily an extension to the readelf.py tool?
This PR does not improve the coverage of the elftools library itself. It only aligns the readelf.py output with the readelf reference implementation. It was for me an exercise to implement a "harmless feature" and go through the PR workflow for the first time.
The reference implementation itself is a moving target, too. First thing, the reference readelf that we have under test/external_tools is not the latest. The version that we have here has spotty DWARFv5 support. On some of the test binaries that we have, it would just provide bogus values, then error out. And DWARFv5 is 5 years old by now.
The latest master of readelf as of June has gratuitous changes in output format. Trying to adopt it would cause even more maintenance pain here and more importantly, it would require changes in the core library, when it comes to enumerating loclists and rangelists. "Give me a collection of all rangelists" is not a well defined operation, seeing that rangelists may and do overlap. Same for loclists, seeing that the section is allowed to have gaps. llvm-dwarfdump and readelf adopt explicitly different approaches here. So in order to implement an autotest against both, we'd need to support both versions of the logic.
The two approaches to enumeration correspond, vaguely, to aiming for utility and aiming for fidelity. One is better for practical debugging, the other is better for testing DWARF parsers against.
OBTW, I've submitted 4 bugs for readelf back in June, and two are still unfixed.