[llvm-dev] RFC: Add DWARF support for yaml2obj (original) (raw)

Pavel Labath via llvm-dev llvm-dev at lists.llvm.org
Thu May 21 02:41:51 PDT 2020

• Previous message: [llvm-dev] RFC: Add DWARF support for yaml2obj
• Next message: [llvm-dev] RFC: Add DWARF support for yaml2obj
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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 .debugabbrev section when this is desired after you are done? Yes, I think it works. There are two ways to edit the .debugabbrev section. i) Edit the "Attr:" and "Form:" entries of a DIE in the ".debuginfo" section. This controls the generation of the ".debugabbrev" section at a high level since "yaml2obj" generates the ".debugabbrev" section according to the contents from debug information entries. ii) Edit the ".debugabbrev" directly. This controls the generation of the ".debugabbrev" 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 "debuginfo" entry in the "DWARF". Additionally, if we have the "debuginfo" entry and the "debugabbrev" entry at the same time, the latter one will overwrite the tags and attributes generated by the former one. Does it make sense?

• Previous message: [llvm-dev] RFC: Add DWARF support for yaml2obj
• Next message: [llvm-dev] RFC: Add DWARF support for yaml2obj
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the llvm-dev mailing list