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

[Paul Robinson via Phabricator via llvm-commits]

probinson 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
+
----------------
aprantl wrote:
> 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.
I am pretty sure that with a checked-in binary, you don't need to build the right target architecture to be able to dump it.  For sure assembling the file at test time will depend on having llvm-mc built with the correct target.  But overall I think being able to show the cross-section stuff works for both Mach-O and ELF is probably more important than being able to run an ELF-only test on bots that don't build X86.  So I will proceed with trying to find a reasonable way to make the assembly source work for both ELF and Mach-O.


https://reviews.llvm.org/D33155