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

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

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.

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).
- 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? Can I change their forms? etc.

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?
>

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