Missing `DW_AT_abstract_origin` debug info in outlined function generated by partial inlining

[tianqingw]

Reproducer: Godbolt

In the reproducer, both GCC and Clang do partial inlining for foo(), but they generate different debug info for the outlined function:

• GCC

  0x000003e1:   DW_TAG_subprogram
                 DW_AT_abstract_origin    (0x0000025a "foo")
                 DW_AT_low_pc (0x0000000000000000)
                 DW_AT_high_pc    (0x0000000000000166)
                 DW_AT_frame_base (DW_OP_call_frame_cfa)
                 DW_AT_call_all_calls (true)

• Clang

  0x0000025f:   DW_TAG_subprogram
                  DW_AT_low_pc    (0x0000000000000040)
                  DW_AT_high_pc   (0x000000000000019e)
                  DW_AT_frame_base    (DW_OP_reg7 RSP)
                  DW_AT_linkage_name  ("foo.1.extracted")
                  DW_AT_name  ("foo.1.extracted")

I'm not sure whether we should take GCC's emission as standard. But a nice property of it is that one can easily infer the name of the source function from DW_AT_abstract_origin, while with the Clang debug info, the only way doing this is decoding the mangled name.

The same issue may also be applicable for other optimizations using CodeExtractor (e.g. HotColdSplitting).

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Tianqing Wang (tianqingw)

Reproducer: [Godbolt](https://godbolt.org/z/6jMGxKrex) In the reproducer, both GCC and Clang do partial inlining for `foo()`, but they generate different debug info for the outlined function: * GCC ``` 0x000003e1: DW_TAG_subprogram DW_AT_abstract_origin (0x0000025a "foo") DW_AT_low_pc (0x0000000000000000) DW_AT_high_pc (0x0000000000000166) DW_AT_frame_base (DW_OP_call_frame_cfa) DW_AT_call_all_calls (true) ``` * Clang ``` 0x0000025f: DW_TAG_subprogram DW_AT_low_pc (0x0000000000000040) DW_AT_high_pc (0x000000000000019e) DW_AT_frame_base (DW_OP_reg7 RSP) DW_AT_linkage_name ("foo.1.extracted") DW_AT_name ("foo.1.extracted") ``` I'm not sure whether we should take GCC's emission as standard. But a nice property of it is that one can easily infer the name of the source function from `DW_AT_abstract_origin`, while with the Clang debug info, the only way doing this is decoding the mangled name. The same issue may also be applicable for other optimizations using CodeExtractor (e.g. HotColdSplitting).

[dwblaikie]

There's some discussion in the DWARF Committee on an issue related to how to represent some of these sort of situations I think - so probably best to see how that settles out before making changes here.