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

[Xing GUO via llvm-dev]

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