llvm dev - May 2020 - RFC: Add DWARF support for yaml2obj

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

On Fri, 22 May 2020 at 10:46, Pavel Labath via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 22/05/2020 10:38, Xing GUO wrote:
> >  BTW, I think
> > the value of "DW_AT_decl_file" shall be "Str"? Can
we map the values
> > of different types into same field?
> >
> > """
> > - Attr: DW_AT_decl_file
> >   Str: foo
> > """
> Yes, that is definitely possible. You just need to make the map calls
> conditional on the values of other attributes. Maybe something like this:
> IO.mapRequired("Attr", Attr);
> IO.mapOptional("Form", Form, getDefaultForm(Attr,
Ctx.isSplitDwarf()
> /*or whatever*/));
> switch (getFormClass(Form)) {
> /* The cases could correspond to DWARF5 form classes, but maybe not
> completely.*/
> case String: IO.mapRequired("Value", Value.String);
> case Constant: IO.mapRequired("Value", Value.Int);
> case Block: IO.mapRequired("Value", Value.Bytes);
> ...
> }
>
>
> I think doing something like that would be reasonable, because i expect
> a relatively high number of "classes", and I think it might be
tricky to
> remember which key to use for which value type.
>
> cheers,
> Pavel
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200522/4ef40009/attachment.html>

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

Hi there,

Thank you for giving suggestions and leaving comments on this topic.
I've almost finished porting existing DWARF sections to yaml2elf. I'm
going to implement the .debug_rnglists/.debug_loclists and do some
refactor work according to the proposal. After porting the existing
DWARF sections to yaml2elf, I learned a lot of new things and found
some places that need to improve. A report[1] is drafted to record
these things. Thank you all for participating in the discussion.

[1]
https://docs.google.com/document/d/1VgtH9VMnzEn2ii3j5UM-aQTWdA25PGr_9FRxXlXQpVU/edit?usp=sharing

On 5/22/20, Pavel Labath <pavel at labath.sk>
wrote:
> 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
>

-- 
Cheers,
Xing