[PATCH] D33155: [DWARFv5] Support FORM_strp in the line table header

[Adrian Prantl via Phabricator via llvm-commits]

aprantl added inline comments.


================
Comment at: llvm/test/DebugInfo/Inputs/dwarfdump-header-64.s:7
+# llvm-mc -triple x86_64-unknown-linux dwarfdump-header-64.s -filetype=obj \
+#         -o dwarfdump-header-64.elf-x86-64
+
----------------
probinson wrote:
> aprantl wrote:
> > Why do we need/want to check in the binary? Could it just be generated on the fly?
> > 
> > It looks like this assembler file may be general enough to also assemble for am x86_64-apple-darwin triple so we could test Mach-O support, too?
> I thought checked-in binaries were usual; for example the DWARF32 version of the test is a checked-in binary.  Generating the binary on the fly has a small test-time performance cost.
> I don't actually know if Mach-O would be okay with this, because section names?  I'm happy to do it that way if there's a coverage benefit.  I'll play with it and see what happens.
We don't have a clear policy for binary files. My opinion is that we should avoid binaries where a sufficiently reliable alternative exists, to make it easier to modify and maintain testcases in the future. So unless we need to become independent from variability introduced by llvm-mc, I think just checking in the assembler sources is the way to go. A counterexample for when binaries are necessary are the LLVM bitcode compatibility tests.

For completeness: another alternative is yam2obj, but it is even more low-level than assembler and in my experience too verbose for DWARF tests.

>  because section names?
Good point, I forgot about those. Half-serious: we could run the C preprocessor over the assembler file to support alternate section names guarded by #ifdefs.


https://reviews.llvm.org/D33155