[PATCH] D30206: [DWARF5] Emit new unit header

[Robinson, Paul via llvm-commits]

aprantl wrote:
> This should probably be tested by a llvm-dwarfdump test?
Are there llvm-dwarfdump tests?

There are some - using checked in binary/object files.

  I couldn't find any.  There is a test/tools/llvm-dwarfdump directory (with AArch64 and ARM subdirectories) but not actual files.

There are some in test/DebugInfo/dwarfdump* I think.

okay….  I can see an argument for having them there, as it's really the DebugInfo library and llvm-dwarfdump is basically just a frontend for the library.  If that's where people want them, okay.

Checked-in binaries seems like overkill in some cases.  For .debug_info stuff I'd be more inclined to start with assembler source, run llvm-mc, and dump the result.  Can't do that for things the assembler actually produces, like line tables, but for a lot of things it would be easier to deal with.

This code was needed because there are a couple of debug-info tests that specify version 5 in the IR, and then use llvm-dwarfdump in their RUN lines.  Having done this change, I had to fix the unit-test DWARF generator because the unit tests were failing.

What was it that caused breakage in the DwarfGenerator once llvm-dwarfdump had v5 support?

Some of the unit tests (I think these are ones that Greg Clayton added relatively recently) are designed to run on both v4 and v5.  Once the DebugInfo APIs started treating the v5 header differently, the unit tests broke for v5 because the generator emitted a v4-format header with version=5.  This meant the generator put the abbrev table pointer at offset 6 in the header, but DebugInfo was looking for it at offset 8.  With a bogus abbrev table pointer, the DIEs didn't decode as expected, and the tests failed. So I fixed the generator to emit the correct v5 format.

--paulr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170221/4f080169/attachment.html>