[llvm-dev] RFC: Add DWARF support for yaml2obj

[Pavel Labath via llvm-dev]

On 22/05/2020 12:28, James Henderson wrote:
> I think we have to be careful here. We might want flexibility to say "I
> want to use a specific class" without having to specify the exact
> DW_FORM. Sometimes, we might even end up in an ambiguous situation and
> not get the result we want. For example, in DWARFv4, the DW_AT_high_pc
> attribute has either a Constant or an Address class, which use
> completely different forms, but if we have just "Value: 0x1234", which
> is it? In DWARFv3, it is always an Address, if I remember correctly, so
> in that case, we might want our default to be "Address". However, for
> DWARFv4 the compiler typically emits DW_AT_high_pc using a Constant
> form, and most people might expect that to be used instead.
> 
> I think having a different name for the tag might be a good thing to do,
> with the name matching the different classes (of which there are 15 in
> DWARFv5, possibly with some folded together like string/stroffsetsptr),
> but it could be a little confusing as Pavel mentions. Alternatively,
> maybe we could have Value and Form, where the Form can be a generic
> class name instead of a specific DW_FORM value. This has the potential
> for ambiguity still, but should be flexible enough at least.
> 
> James

Hello James,

The DW_AT_high_pc example is a good one. For this attribute, I guess I
would say that we shouldn't have any "default" form class.

Encoding the form class into the yaml key achieves this implicitly (for
all attributes). I sort of like that -- it results in a pretty concise
representation for the cases where one does not want to specify a form.
On the other hand, it feels a bit redundant in the cases where one does
specify a form.

The idea of making "generic" form values also sounds interesting. I'm
not sure how much will they be used though -- most of the files are made
by copy-pasting, and I'm guessing the obj2yaml path will not be
producing these. And people who know about form classes, probably don't
have a problem with specifying an explicit form either. However, I don't
think it hurts having them anyway.

I don't really have a strong opinion on any of these options. I'm
guessing we'll need to play around with some actual examples to see how
they would look for real.

regards,
pavel