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.

[eliben]

@sevaa

If I'm understanding correctly, I would like to avoid "bug compatibility" fixes inside pyelftools; we've generally been avoiding this, and instead have selective skipping or relaxing of specific tests in the readelf-compatibility testing suite. Would it be possible to go that way?

[sevaa]

We've removed individual testfiles from the readelf autotest in the past, and that's what this PR currently does :) Eventually, readelf would catch up.

If #526 is merged, this will break - they both add sections to the DWARFInfo constructor .

[eliben]

It's ok for now, then.

Re merge conflict - yes. @dinkark-dev can you rebase this PR on the main branch?

[sevaa]

OBTW, the aranges section in that binary is malformed, and this is squarely the toolchain's fault. The DWARF format (section 7.21 in v5) requires that address/length entries in aranges be aligned within the section to the entry size (8 bytes on ARM32). The header is 12 bytes, so there needs to be a 4 byte padding between the header and the entries. This binary doesn't have the gap, hence the premature stream end error.

Same thing in dwarf_v4cie.elf - also by the IAR compiler. I've sent them a support e-mail, but this won't fix the binaries already in the corpus.

In conclusion, removing the binary from the autotest is entirely justified.

[sevaa]

@dinkark-dev the IAR support is asking for an EWARM license number. Can you share one please?

[sevaa]

@Maxicu5 you are an IAR user, right? Do you have a license number I could use for their support?

[Maxicu5]

@Maxicu5 you are an IAR user, right? Do you have a license number I could use for their support?

I cannot share the number because of security politics, but I can ask needed questions and share the answers from IAR support

[sevaa]

Understandable. In that case, can you please fill out the support request form at https://www.iar.com/about/contact -> Customer support with the following issue description (copy-pasted from my ticket):

---

I have a handful of compiled binary files, all generated by IAR. The debug_aranges section in those binaries is malformed. According to DWARF format (section 7.21 in DWARFv5), the address/length entries (tuples) in the aranges section must be aligned, within the section, to the entry size - 8 on 32-bit ARM. This means there should be a padding gap between the CU header (which is 12 bytes) and the entries. In the binaries by IAR, there isn't any gap. Third party, standard compliant DWARF tools choke on that.

To reproduce, build a "hello world" type program with IAR for ARM32, with debug symbols enabled, and use an ELF viewer of your choice (readelf, objdump, XELFViewer) to see the size of the debug_aranges section. If it's not a multiple of 8 - the issue persists.

---

Feel free to give them my e-mail - [email protected] - if they have questions about reproduction. For product version, use "IAR ANSI C/C++ Compiler V9.20.4.327/W64 for ARM".

[Maxicu5]

I've created a case, and technical support engineer has replied that he will try to reproduce

[sevaa]

Thanks. Is there a case number? Mine was 00342995.

[sevaa]

@dinkark-dev: looks like the aranges bug has been addressed in the latest IAR (v9.40). Would it be possible to update the compiler and rebuild the test binary?