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

Hi Pavel,

Thanks for your comments!

On 5/21/20, Pavel Labath <pavel at labath.sk>
wrote:
> Hello Xing,
>
> I think the proposal looks very useful. I think it will be fairly tricky
> to get all of the details right though. There is a lot of
"inferring"
> going on there, and getting that to work reliably and with predictable
> results will need careful consideration.
Yes, I agree. The proposal gives an ideal example of DWARF YAML. We
will try to make the final implementation close to that example.
> Some ideas/questions I had while looking this over:
> - It seems like it would be useful to be able to (symbolically) refer to
> other parts of the debug information, much like one can refer to elf
> symbols and sections from e.g. relocation descriptions. For example, if
> each "abbrev" contribution had some kind of a name/identifier,
then one
> could easily express that two compile units share the same abbreviation
> table. At the same time, one could control their relative order by using
> those identifiers in the debug_abbrev section (while leaving some of
> them to be auto-generated, and spelling out others, for instance).
Nice catch! It's a useful feature, but I cannot give an answer right
now. I will be back to this thread, once I have some ideas on this.
> - It's not clear to me whether having a "SourceLocation"
entry as a
> first class entity is really worth it. This
> """
>   - SourceLocation:
>     - File: foo
>     - Line: 1
>     - Column: 2
> """
> is not that much shorter than
> """
>   - Attr: DW_AT_decl_file
>     Value: foo
>   - Attr: DW_AT_decl_line
>     Value: 1
>   - Attr: DW_AT_decl_column
>     Value: 2
> """
> OTOH, it creates a lot of opportunities for ambiguity: What if a DIE has
> both a SourceLocation entry and an explicit DW_AT_decl_file attribute?
> Do the "SourceLocation" attributes come first or last in the
final
> attribute list?
Thanks, it makes sense. I will fix the proposal later. 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
"""
>
> regards,
> pavel
>
> On 21/05/2020 10:47, Xing GUO via llvm-dev wrote:
>> On 5/21/20, Adrian Prantl <aprantl at apple.com> wrote:
>>> I think the example looks like it would be really useful for many
>>> categories
>>> of testcases!
>>> Will it still be possible to manually specify the .debug_abbrev
section
>>> when
>>> this is desired after you are done?
>>
>> Yes, I think it works. There are two ways to edit the .debug_abbrev
>> section.
>>
>> i) Edit the "Attr:" and "Form:" entries of a DIE in
the ".debug_info"
>> section. This controls the generation of the ".debug_abbrev"
section
>> at a high level since "yaml2obj" generates the
".debug_abbrev" section
>> according to the contents from debug information entries.
>>
>> ii) Edit the ".debug_abbrev" directly. This controls the
generation of
>> the ".debug_abbrev" section at a low level. We will have to
hardcode
>> the tag and attributes for each DIE. Editing the section in this way
>> doesn't need a "debug_info" entry in the
"DWARF".
>>
>> Additionally, if we have the "debug_info" entry and the
"debug_abbrev"
>> entry at the same time, the latter one will overwrite the tags and
>> attributes generated by the former one.
>>
>> Does it make sense?
>>
>
>

-- 
Cheers,
Xing

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

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>