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

[Pavel Labath via llvm-dev]

(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:
> 
>   label:
> 
> To make it global:
> 
>   .globl label
>   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
> write/read.

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.

regards,
pl