[llvm-dev] [yaml2obj] GSoC-20: Add DWARF support to yaml2obj

Adrian Prantl via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 31 09:29:36 PDT 2020

It's great to see someone interested in improving yaml2obj!

As far as I'm concerned, the main problem with yam2obj for DWARF testcases is that at the moment, it is both too high-level and too low-level at the same time. For writing debug info testcases, yaml2obj at the moment does not add anything on top of assembler. If it is only providing an alternative syntax, and no other features, it isn't that useful. Let me explain what I mean:

1. Too high-level
For testing parsers we need to be able to create malformed input, so we need to be able to manually tweak offsets and headers where necessary. IIRC currently yaml2obj always creates section headers automatically, and can do so for only one DWARF version. It would be valuable to support more than one version of DWARF, and to support them on a per-section basis (it is not uncommon to mix a DWARF 5 .debug_info section with a DWARF 4 line table). Also there needs to be a way to optionally manually specify headers byte-for-byte, for when we do need this.

2. Too low-level

For functionality tests, however, we don't want to hardcode things like byte offsets, because it makes it extremely hard to write/modify tests by hand. It would be awesome if yaml2obj could automatically generate abbreviation sections if the user requests it, if their exact layout isn't relevant to the test. Similarly, having to manually adjust object file metadata, such as Mach-O section load commands or ELF headers every time we're editing a test in a way that changes the size of, e.g., the .debug_info section prevents us from using yaml2obj for any kind of hand-written tests.

The tasks you are describing to add explicit syntax for more DWARF constructs are also good and necessary, but addressing one or both of these problems would be even more important to increase the usefulness of yaml2obj for DWARF testing.

-- adrian

More information about the llvm-dev mailing list