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

[Xing GUO via llvm-dev]

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