Support for parsing .debug_types section introduced in DWARF version 4

[dinkark-dev]

Adds support for parsing the .debug_types section introduced in DWARF version 4.

Intends to address the issue #193

Changes:

• Support for parsing type units from the .debug_types section
• Added logic to generate debug_types with readelf tool
• Added test binaries generated using IAR Embedded Workbench for ARM toolchain (dwarf_debug_types.elf)

Known issues:
When running unit tests with new ELF binaries generated using the IAR EWARM toolchain,

• Parsing of the .debug_frames section results in an infinite loop
• Parsing of the .debug_aranges section causes stream parsing errors

Credits:
Builds over .debug_types updates introduced in #265

[sevaa]

Just a heads up, please run the autotests locally and follow up until they all succeed. If you add binaries to the corpus, it's up to you to make sure the autotest doesn't fail on those - regardless of the primary purpose of the PR. I, too, had to debug unrelated discrepancies on readelf/dwarfdump, and the library only became better for that.

On Windows it's doable too, but somewhat trickier.

[sevaa]

@dinkark-dev : are you working on this?

[dinkark-dev]

Yes, I am working on it. However, I am not quite familiar with the .debug_frames or .debug_aranges sections thus it's taking a while.

[driftregion]

Hi @dinkark-dev, thanks for your work on this. I've pushed a test binary generated by TI Code Composer Studio for a TMS320 device to https://github.com/driftregion/pyelftools/blob/dinkar/dwarf-v4-debug-types-support/test/testfiles_for_dwarfdump/dwarf_ticcs.elf

It contains DW_FORM_ref_sig8 tags which pyelftools 0.30 does not yet handle.

[sevaa]

@eliben

The issue with the frames section that plagues the binary in this PR is the same as in #563: FDE before its corresponding CIE. The infinite loop was fixed in #563, but the mismatch with readelf stays. Binutils' bug records at https://sourceware.org/bugzilla/show_bug.cgi?id=31975 and https://sourceware.org/bugzilla/show_bug.cgi?id=31973 have been sitting there since July 2024; the latter even has a proposed fix patch, but no reaction from the maintainers so far.

I have a fairly good idea how to reproduce the faulty behavior of readelf in pyelftools - but it won't be a descriptions only fix, it will have to go deep into the parser, introducing a "readelf compatible" mode to CallFrameInfo._parse_entry_at and upstack. With more effort, I could submit a patch to binutils for 31975 too - that's the right thing to do in the long run, but who knows when will it see the light of day.

I didn't see a readelf mismatch with aranges in this binary.