[PATCH] D36993: [llvm-dwarfdump] Print type names in DW_AT_type DIEs

[Adrian Prantl via Phabricator via llvm-commits]

aprantl added a comment.

I played around with how we could generate testcases for this.

- I'm absolutely certain that yaml2obj (the standalone tool) is too low-level to do this. Having to manually update the object file header (or Mach-O load commands) every time a section changes in size is not doable unless you are starting from an existing object file and only modifying a couple bytes to inject, e.g., an error.
- Using just the yaml2obj DWARF emitter like in the `DWARFDebugInfoTest.cpp` unittest is slightly better, but you still have to manually update the size of the CU header and compute all offsets by hand. Plus IMHO the use of yaml in a string constant is kind of weird., but I can get used to it.
- Using assembler allows using labels, which gets rid off all the error-prone offset calculation, but on the other hand is much more verbose and low-level than some aspects of yaml2obj.
- Using LLVM IR is much more compact than all of the above, but it has the drawback that we can only represent DWARF that LLVM can generate,
- Source code is the most compact representation, but difficult to integrate into the LLVM testsuite because of the frontend dependency. It also restricts what DWARF we can generate even more.

What I would want is a format where I can specify DWARF at the same level of abstraction that dwarfdump is presenting. The easiest way to achieve this is probably to generate the DWARF programmatically in a unit test using the same API that yaml2obj is using internally. This way I can at least write code to calculate all the offsets. It would be kind of cute to write a tool that takes dwarfdump-like output as input and emits a yaml2obj-like yaml file, but I feel that that would be overkill since it isn't going to be very useful outside of this patch.

I will think some more about this.


Repository:
  rL LLVM

https://reviews.llvm.org/D36993