[llvm] [RFC] Emit dwarf data for signature-changed or new functions (PR #157349)
via llvm-commits
llvm-commits at lists.llvm.org
Mon Sep 22 12:48:15 PDT 2025
yonghong-song wrote:
> Was usage DWARF trampolines considered? As it is stated in section 3.3.9 of DWARF standard (https://dwarfstd.org/doc/DWARF5.pdf):
>
> ```
> A trampoline is a compiler-generated subroutine that serves as an intermediary in
> making a call to another subroutine. It may adjust parameters and/or the result (if any)
> as appropriate to the combined calling and called execution contexts.
> ```
>
> Can DW_TAG_subprograms with DW_AT_trampoline serve the purpose, for which DW_TAG_inlined_subroutines are created in this patch? DwarfDebug can already produce subprogram DIEs with DW_AT_trampoline, and LLVM IR of `llvm/test/DebugInfo/X86/disubprogram-trampoline.ll` is similar to what we're trying to solve in the sense that a function like "func.suffix" (sub1_.t0p in the test) should refer to the original "func" in DWARF.
I am not really familiar with DW_AT_trampoline. But if I understand correctly, the proposal is to generate the following (for signature changed functions or new functions):
```
DW_TAG_subprogram
DW_AT_name ("foo")
DW_AT_type (0x0000000000000091 "int")
DW_AT_artificial (true)
DW_AT_trampoline (original DW_TAG_subprogram)
DW_TAG_formal_parameter
DW_AT_name ("b")
DW_AT_type (0x0000000000000091 "int")
DW_TAG_formal_parameter
DW_AT_name ("c")
DW_AT_type (0x0000000000000095 "long")
```
I have a few worries about the above.
First, let us say the function 'foo' has its signature changed. With the above, we will have two DW_TAG_subprogram's which has the same name 'foo'. This will cause confusion. One option is to directly replace the *old* signatures with *new* signature. But the existing DW_TAG_subprogram has been parsed/used in many tools. Changing signature might cause issues for those tools.
Second, some tools may not be aware of DW_AT_trampoline so they may parse DW_TAG_subprogram the same as other existing DW_TAG_subprogram's and this may have some side effects on their results.
Are the above concerns valid?
https://github.com/llvm/llvm-project/pull/157349
More information about the llvm-commits
mailing list