[llvm-dev] [yaml2obj] GSoC-20: Add DWARF support to yaml2obj
Pavel Labath via llvm-dev
llvm-dev at lists.llvm.org
Fri Apr 24 06:21:49 PDT 2020
(Reviving this thread because a code review reminded me I want to reply
here. Sorry for the extremely long turnaround).
On 31/03/2020 20:22, Fangrui Song wrote:
> On 2020-03-31, Adrian Prantl via llvm-dev wrote:
>>> On Mar 31, 2020, at 10:55 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>> +1 to all that & cc'ing a few of the usual suspects as FYI
>>> On Tue, Mar 31, 2020 at 10:36 AM Pavel Labath via llvm-dev
>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> For me personally, the ability to write/edit syntactically correct dwarf
>>> easily is much more important than being able to generate "incorrect"
>>> dwarf -- I'm perfectly happy to continue to write the latter in
>>> assembly, but there is a lot that could be improved about the experience
>>> of writing "correct" dwarf. Ideally, I'd have a mode where I can just
>> Do we think that yaml2obj is the best format for this, or would
>> high-level DWARF DIE assembler directives be a more useful abstraction
>> level? If you think about the .loc directive, there is actually some
>> prior art in assembler.
>> -- adrian
> I also find YAML tests unwieldy but for some tests (especiall malformed)
> we may have to use them because it is diffult for an assembly directive
> to produce invalid output (invalid offset/relocation/string table/etc).
> An assembly syntax can be conciser than its YAML counterpart, e.g. to
> describe a section:
> assembly: .section .foo,"a", at progbits
> YAML: - Name: foo
> Type: SHT_PROGBITS
> Flags: [ SHF_ALLOC ]
> A symbol table entry is similar. A YAML entry usually takes several
> lines of code.
> Another advantage of assembly syntax is that it is composable. To define a
> local symbol:
> To make it global:
> .globl label
> Some directives are more expressive, e.g. .file .loc
> An assembler even supports some meta programming features (macros). The
> syntax may be strange.
> We do need some composable directives to make DWARF tests easier to
I am agree with David that we shouldn't add first class DWARF-generation
directives to the assembler just for the sake of writing tests.
However, I do see the appeal of assembler metaprogramming, and I have
used it on occasion when generating some DWARF. A separate utility with
some (meta-)programming facilities could be interesting, though it would
be an additional burden to maintain, and I am not sure it is really
needed (in tests, repetition is often better than complex control flow).
I am curious about your comment on invalid relocations et al. I can see
how that is interesting for testing binary utilities (and I don't think
anyone wants to take that away), but I am not sure how useful is that in
the context of DWARF testing, except maybe in a couple of low-level
DWARF tests (which could be done in the traditional elf yaml and the
DWARF could be written as a blob of bytes). If you have some examples
like that, I'd very much like to about it.
More information about the llvm-dev