[llvm] [Dwarf][Transforms] Add dwarf support when func signature changed (PR #127855)
via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 3 13:43:30 PDT 2025
yonghong-song wrote:
> DW_AT_artificial means "this entity is not represented explicitly in the source" which is kind of the opposite of what is actually going on--it's the inlined version that's artificial. Also, this construct allows for only one inlined/modified version; if there are two different instances with two different signature modifications, there's no way to describe both of them.
>
> Now, I could see flagging the DW_TAG_inlined_subroutine with DW_AT_artificial, and using the normal DW_AT_specification to point back to the DW_TAG_subprogram, but still providing the parameter details on the inlined_subroutine. Maybe this was already described above, and there's a reason not to do it that way, sorry I didn't go back and reread the entire thread.
Thanks @pogo59, you suggest having the following?
```
DW_TAG_subprogram
DW_AT_low_pc (0x0000000100003ed8)
DW_AT_high_pc (0x0000000100003f18)
DW_AT_frame_base (...)
DW_AT_name ("foo")
DW_TAG_formal_parameter
DW_AT_name ("a")
DW_AT_type (0x0000000000000091 "int")
DW_TAG_formal_parameter
DW_AT_location
DW_AT_name ("b")
DW_AT_type (0x0000000000000095 "float")
DW_TAG_formal_parameter
DW_AT_location
DW_AT_name ("c")
DW_AT_type (0x0000000000000025 "char")
NULL
DW_TAG_inlined_subroutine
DW_AT_type (0x0000000000000091 "int")
DW_AT_artificial (true)
DW_AT_specificiation (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 "float")
```
For your below worry
```
Also, this construct allows for only one inlined/modified version; if there are two different instances with two different signature modifications, there's no way to describe both of them.
```
Currently, for clang, we only care the signature change but func name remains the same. This refers to static functions. In the same file, there should be no two different signatures.
If func name changed, we would like just create a dwarf entry with that changed signature since changed func name will be available in elf file symtol table and we want to keep name consistent between dwarf and symbol table.
What do you think my above proposal? cc @jemarch
https://github.com/llvm/llvm-project/pull/127855
More information about the llvm-commits
mailing list