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

[Pavel Labath via llvm-dev]

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