Inlined subroutine should own its call site entries, not the parent subprogram

[jryans]

When the following source is compiled...

#include <stdio.h>

struct config_source {
  FILE *file;
};

int config_file_fgetc(struct config_source *conf) {
  return getc_unlocked(conf->file);
}

...getc_unlocked (from system headers) is inlined into config_file_fgetc, and a call site entry is added for a call to __uflow that happens inside getc_unlocked:

0x000001fa:     DW_TAG_call_site
                  DW_AT_call_origin	(0x00000201 "__uflow")
                  DW_AT_call_tail_call	(true)
                  DW_AT_call_pc	(0x000000000000000b)

With Clang, the call site entry is a child of the subprogram DIE for config_file_fgetc, while GCC adds the call site entry as a child of the inlined subroutine DIE for getc_unlocked (where the call occurs).

The DWARF 5 spec says (sec. 3.4.1):

A call site is represented by a debugging information entry with the tag DW_TAG_call_site. The entry for a call site is owned by the innermost debugging information entry representing the scope within which the call is present in the source program.

The spec text suggests to me that the GCC interpretation is correct (call site entry inside inlined subroutine DIE where call occurred), and Clang / LLVM should be changed to match. The GCC approach also conveys slightly more information, since it is obvious who the caller is, whereas with Clang variant, it could be the subprogram or any inlined subroutine within it.

Example available on Compiler Explorer

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: J. Ryan Stinnett (jryans)

When the following source is compiled...

#include <stdio.h>

struct config_source {
  FILE *file;
};

int config_file_fgetc(struct config_source *conf) {
  return getc_unlocked(conf->file);
}

...getc_unlocked (from system headers) is inlined into config_file_fgetc, and a call site entry is added for a call to __uflow that happens inside getc_unlocked:

0x000001fa:     DW_TAG_call_site
                  DW_AT_call_origin	(0x00000201 "__uflow")
                  DW_AT_call_tail_call	(true)
                  DW_AT_call_pc	(0x000000000000000b)

With Clang, the call site entry is a child of the subprogram DIE for config_file_fgetc, while GCC adds the call site entry as a child of the inlined subroutine DIE for getc_unlocked (where the call occurs).

The DWARF 5 spec says (sec. 3.4.1):

> A call site is represented by a debugging information entry with the tag DW_TAG_call_site. The entry for a call site is owned by the innermost debugging information entry representing the scope within which the call is present in the source program.

The spec text suggests to me that the GCC interpretation is correct (call site entry inside inlined subroutine DIE where call occurred), and Clang / LLVM should be changed to match. The GCC approach also conveys slightly more information, since it is obvious who the caller is, whereas with Clang variant, it could be the subprogram or any inlined subroutine within it.

Example available on Compiler Explorer

[dwblaikie]

Yeah, seems to reproduce in this simple example too:

void f1();
inline void f2() {
  f1();
}
void f3() {
  f2();
}

clang++-tot test.cpp -g -O1 -c && llvm-dwarfdump-tot test.o

0x00000023:   DW_TAG_subprogram
                DW_AT_linkage_name      ("_Z2f2v")
...
0x00000028:   DW_TAG_subprogram
                DW_AT_linkage_name      ("_Z2f3v")
...
0x00000034:     DW_TAG_inlined_subroutine
                  DW_AT_abstract_origin (0x00000023 "_Z2f2v")
...
0x00000041:     DW_TAG_call_site
                  DW_AT_call_origin     (0x00000048 "_Z2f1v")