Description

Following up on this issue about llvm-dwarfdump warnings from a while back, it turns out that the patch to fix these issues actually resulted in a more malformed binary than before.

Running llvm-dwarfdump on a generated Linux binary created from the latest NativeAOT results in a significantly truncated output. In my test case, dwarfdump claims that the next unit of the executable file (after .debug_info) starts at offset 0x0042e539, but the actual dwarfdump output only reaches 0x00000db7. When I roll back to before the linked objwriter commit and rebuild, the dwarfdump output goes all the way up to the expected offset.

I did some testing and the reason this is happening is because objwriter is incorrectly inserting a NULL terminator as a sibling of static+no parameters MethodInfo DIEs. This messes up the hierarchy and results in the DWARF output "ending" earlier than it should.

Incidentally, this is the reason that llvm-dwarfdump --verify no longer emits any warnings. It stops dumping the file before it gets a chance to actually detect problems! If the above issue is fixed/worked around, the other dwarfdump errors I mentioned in my original issue are still around.

Additionally, no file/line information is given for any DIEs in the dwarf info. For the filename, every DIE writes whatever arbitrary filename happened to be compiled first (often some obscure file in the .NET runtime code), and Line 1 for the line info. This seems to be causing issues with certain debuggers, so while this isn't technically a spec violation, it should still be addressed.

Reproduction Steps

Run llvm-dwarfdump on a NativeAOT linux debug binary. Note this info at the top:

.debug_info contents:
0x00000000: Compile Unit: length = 0x0042e535 version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x0042e539)

then scroll down to the end of the output, and note the actual ending offset. These will not match.

Expected behavior

Output from llvm-dwarfdump should reach all the way to the offset given at the top of the output, and not stop prematurely.

Additionally, llvm-dwarfdump --verify should produce no warnings, and the DIEs in the debug info should have accurate file/line information.

Actual behavior

The dwarfdump output is truncated, and even when that issue has been fixed, the debug info is still full of errors.

Regression?

The truncation is a regression caused by this commit, but everything else seems to have been around for all of objwriter's existence.

Known Workarounds

If I guard the final line of DwarfMemberFunctionIdTypeInfo::DumpTypeInfo() so that it only emits the NULL terminator at the end if the dwarf abbreviation chosen early in the function is not DwarfAbbrev::SubprogramStaticNoChildrenSpec, then the dwarfdump output does not get truncated.

Configuration

No response

Other information

No response