DW_TAG_compile_unit's references to .debug_line and .loc directive extension

DW_TAG_compile_unit's references to .debug_line and .loc directive extension

[Fangrui Song]

I have noticed that Meta Platforms folks have a proposal to extend the
.loc directive https://discourse.llvm.org/t/rfc-extending-llvm-mc-loc-directive-with-labeling-support/79608
 .
I filed https://sourceware.org/bugzilla/show_bug.cgi?id=31955 ("gas:
Extend .loc directive to emit a label") and am sending this message in
case there are interest/opinions.

For your convenience, the gas documentation is at
https://sourceware.org/binutils/docs/as/Loc.html

> The .loc directive will add a row to the .debug_line line number matrix corresponding to the immediately following assembly instruction.

Here is my summary of their proposal:

Clang will add a new debug mode to emit a DW_AT_LLVM_stmt_sequence
attribute to each DW_TAG_subprogram DIE, referencing the start of a
line number program sequence associated with the subprogram.
(https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434)

```
main:
  .loc 0 1 13  debug_line_label .Lmain_line_entries
  ...

.section .debug_info,"",@progbits
  ...
  .byte   1                               # Abbrev [1] 0xc:0x78
DW_TAG_compile_unit
  .long   .Lline_table_start0             # DW_AT_stmt_list
  ...

  .byte 14                                           # Abbrev [14]
DW_TAG_subprogram
  ...
  .long .Lmain_line_entries - .Lline_table_start0    # DW_AT_LLVM_stmt_sequence

.section        .debug_line,"",@progbits # generated
.Lline_table_start0:
# Conceptually, the .Lmain_line_entries label is emitted at start of a
line number program sequence associated with `main`
```

Advantages.

*Faster symbolization*

Traditional address symbolization involves locating the
DW_TAG_compile_unit DIE and parsing the line number program from the
DW_AT_stmt_list offset.
This process requires skipping unrelated DW_TAG_subprogram DIEs. The
DW_AT_LLVM_stmt_sequence attribute directly points to the relevant
line number program sequence, eliminating unnecessary steps.

*Improved ICF disambiguating*

Identical Code Folding (ICF) can make two line number program
sequences (associated with folded subprograms) indistinguishable.
While DW_AT_LLVM_stmt_sequence doesn't resolve this, it identifies the
associated function. If the caller is known, this additional
information could help disambiguate the correct sequence.

---

ELF/COFF -fno-function-sections and Mach-O .subsections_via_symbols
allow consecutive functions to share the same line number program
sequence.
To utilize DW_AT_LLVM_stmt_sequence better, the sequences should be
split to resemble ELF/COFF -ffunction-sections.

Mach-O doesn't have -ffunction-sections -fno-function-sections
differences and normally needs very few relocations for .debug_line
and the new mode will introduce more like ELF/COFF
-ffunction-sections.

Re: DW_TAG_compile_unit's references to .debug_line and .loc directive extension

[Fangrui Song]

On Thu, Jul 4, 2024 at 12:42 PM Fangrui Song <i@maskray.me> wrote:
>
> I have noticed that Meta Platforms folks have a proposal to extend the
> .loc directive https://discourse.llvm.org/t/rfc-extending-llvm-mc-loc-directive-with-labeling-support/79608
>  .
> I filed https://sourceware.org/bugzilla/show_bug.cgi?id=31955 ("gas:
> Extend .loc directive to emit a label") and am sending this message in
> case there are interest/opinions.
>
> For your convenience, the gas documentation is at
> https://sourceware.org/binutils/docs/as/Loc.html
>
> > The .loc directive will add a row to the .debug_line line number matrix corresponding to the immediately following assembly instruction.
>
> Here is my summary of their proposal:
>
> Clang will add a new debug mode to emit a DW_AT_LLVM_stmt_sequence
> attribute to each DW_TAG_subprogram DIE, referencing the start of a
> line number program sequence associated with the subprogram.
> (https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434)
>
> ```
> main:
>   .loc 0 1 13  debug_line_label .Lmain_line_entries
>   ...
>
> .section .debug_info,"",@progbits
>   ...
>   .byte   1                               # Abbrev [1] 0xc:0x78
> DW_TAG_compile_unit
>   .long   .Lline_table_start0             # DW_AT_stmt_list
>   ...
>
>   .byte 14                                           # Abbrev [14]
> DW_TAG_subprogram
>   ...
>   .long .Lmain_line_entries - .Lline_table_start0    # DW_AT_LLVM_stmt_sequence
>
> .section        .debug_line,"",@progbits # generated
> .Lline_table_start0:
> # Conceptually, the .Lmain_line_entries label is emitted at start of a
> line number program sequence associated with `main`
> ```
>
> Advantages.
>
> *Faster symbolization*
>
> Traditional address symbolization involves locating the
> DW_TAG_compile_unit DIE and parsing the line number program from the
> DW_AT_stmt_list offset.
> This process requires skipping unrelated DW_TAG_subprogram DIEs. The
> DW_AT_LLVM_stmt_sequence attribute directly points to the relevant
> line number program sequence, eliminating unnecessary steps.
>
> *Improved ICF disambiguating*
>
> Identical Code Folding (ICF) can make two line number program
> sequences (associated with folded subprograms) indistinguishable.
> While DW_AT_LLVM_stmt_sequence doesn't resolve this, it identifies the
> associated function. If the caller is known, this additional
> information could help disambiguate the correct sequence.
>
> ---
>
> ELF/COFF -fno-function-sections and Mach-O .subsections_via_symbols
> allow consecutive functions to share the same line number program
> sequence.
> To utilize DW_AT_LLVM_stmt_sequence better, the sequences should be
> split to resemble ELF/COFF -ffunction-sections.
>
> Mach-O doesn't have -ffunction-sections -fno-function-sections
> differences and normally needs very few relocations for .debug_line
> and the new mode will introduce more like ELF/COFF
> -ffunction-sections.

Heads-up: they have created a patch to add the  .loc_label assembler
directive https://github.com/llvm/llvm-project/pull/99710 .

.cfi_label is existing, so .loc_label looks reasonable.