[llvm] [RFC] Emit dwarf data for signature-changed or new functions (PR #157349)

[via llvm-commits]

yonghong-song wrote:

@dzhidzhoev I roughly finished a version which can roughly generate dwarf like
```
LOC_A: DW_TAG_subprogram
                DW_AT_name	("mul")
                DW_AT_linkage_name	("_Z3mulii")
                DW_AT_decl_file	("/app/example.cpp")
                DW_AT_decl_line	(...)
                DW_AT_type	(0x0000003d "int")
                DW_AT_inline	(DW_INL_inlined)

      LOC_B: DW_TAG_formal_parameter
                  DW_AT_name	("num1")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(...)
                  DW_AT_type	(0x0000003d "int")
      LOC_C: DW_TAG_formal_parameter
                  DW_AT_name	("num2")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(...)
                  DW_AT_type	(0x0000003d "int")
     NULL

DW_TAG_subprogram
                DW_AT_low_pc	(0x0000000000000000)
                DW_AT_high_pc	(0x0000000000000006)
                DW_AT_frame_base	(DW_OP_reg7 RSP)
                DW_AT_call_all_calls	(true)
                DW_AT_name	("mul")
                ...

              DW_TAG_formal_parameter
                  DW_AT_location	(DW_OP_reg5 RDI)
                  DW_AT_name	("num1")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(...)
                  DW_AT_type	(0x0000003d "int")

              DW_TAG_inlined_subroutine
                  DW_AT_abstract_origin	(LOC_A "mul")
                  DW_AT_low_pc	(...)
                  DW_AT_high_pc	(...)
                  DW_AT_call_file	("/app/example.cpp")
                  DW_AT_call_line	(...)
                  DW_AT_call_column	(...)

                    DW_TAG_formal_parameter
                            DW_AT_location	(DW_OP_reg5 RDI)
                            DW_AT_abstract_origin	(LOC_B "num1")
                    DW_TAG_formal_parameter
                            DW_AT_location	(DW_OP_reg5 RDI)
                            DW_AT_abstract_origin	(LOC_C "num2")
             NULL
NULL
```
But building linux kernel caused failure with 'pahole' where 'pahole' intends to generate BTF types. The error message from pahole:
```
bpf_lsm_socket_getpeersec_stream (bpf_lsm_socket_getpeersec_stream): skipping BTF encoding of function due to param count mismatch; 4 params != 6 params
```
>From pahole perspective, it founds *two* functions which has identical name 'bpf_lsm_socket_getpeersec_stream' with different number of parameters. Note that in the above, there are two DW_TAG_subprogram with the same name and at the same level.
Since two functions have different signatures, function 'bpf_lsm_socket_getpeersec_stream' will be skipped in vmlinux BTF and this will cause error for later vmlinux build.

So in my opinion, having two DW_TAG_subprogram's at the same level with identical func name probably will break some tools. WDYT?


https://github.com/llvm/llvm-project/pull/157349