Call site entries for declared C++ member functions not reported in debug info

[jryans]

When the following...

class A {
public:
  virtual void setVal(bool v);
  bool validation;
};

class B {
public:
  virtual void setVal(bool v);
  A a;
};

class B1 : public B {
public:
  void setVal(bool v) override { a.setVal(v); }
};

int main(int argc, char **argv) {
  B1 b;
  b.setVal(argc);
}

...is compiled with Clang 21.1.0 at -O2, the call from B1.setVal to A.setVal becomes a tail call:

define linkonce_odr dso_local void @B1::setVal(bool)(ptr noundef nonnull align 8 dereferenceable(24) %this, i1 noundef zeroext %v) unnamed_addr #2 comdat align 2 !dbg !85 {
entry:
    #dbg_value(ptr %this, !84, !DIExpression(), !92)
    #dbg_value(i1 %v, !87, !DIExpression(DW_OP_LLVM_convert, 1, DW_ATE_unsigned, DW_OP_LLVM_convert, 8, DW_ATE_unsigned, DW_OP_stack_value), !92)
  %a = getelementptr inbounds nuw i8, ptr %this, i64 8, !dbg !93
  tail call void @A::setVal(bool)(ptr noundef nonnull align 8 dereferenceable(9) %a, i1 noundef zeroext %v), !dbg !94
  ret void, !dbg !95
}

B1::setVal(bool):
 add    rdi,0x8
 jmp    9 <B1::setVal(bool)+0x9>
    R_X86_64_PLT32 A::setVal(bool)-0x4

...but there is no DW_TAG_call_site DIE marking this as a tail call in debug info. If we check GCC 15.2 at -O2, it has the expected behaviour of using a tail call and also reporting the tail call via DW_TAG_call_site in DWARF.

Example available on Compiler Explorer.

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: J. Ryan Stinnett (jryans)

When the following...

class A {
public:
  virtual void setVal(bool v);
  bool validation;
};

class B {
public:
  virtual void setVal(bool v);
  A a;
};

class B1 : public B {
public:
  void setVal(bool v) override { a.setVal(v); }
};

int main(int argc, char **argv) {
  B1 b;
  b.setVal(argc);
}

...is compiled with Clang 21.1.0 at -O2, the call from B1.setVal to A.setVal becomes a tail call:

define linkonce_odr dso_local void @<!-- -->B1::setVal(bool)(ptr noundef nonnull align 8 dereferenceable(24) %this, i1 noundef zeroext %v) unnamed_addr #<!-- -->2 comdat align 2 !dbg !85 {
entry:
    #dbg_value(ptr %this, !84, !DIExpression(), !92)
    #dbg_value(i1 %v, !87, !DIExpression(DW_OP_LLVM_convert, 1, DW_ATE_unsigned, DW_OP_LLVM_convert, 8, DW_ATE_unsigned, DW_OP_stack_value), !92)
  %a = getelementptr inbounds nuw i8, ptr %this, i64 8, !dbg !93
  tail call void @<!-- -->A::setVal(bool)(ptr noundef nonnull align 8 dereferenceable(9) %a, i1 noundef zeroext %v), !dbg !94
  ret void, !dbg !95
}

B1::setVal(bool):
 add    rdi,0x8
 jmp    9 <B1::setVal(bool)+0x9>
    R_X86_64_PLT32 A::setVal(bool)-0x4

...but there is no DW_TAG_call_site DIE marking this as a tail call in debug info. If we check GCC 15.2 at -O2, it has the expected behaviour of using a tail call and also reporting the tail call via DW_TAG_call_site in DWARF.

Example available on Compiler Explorer.

[OCHyams]

Hi @jryans, thanks for the report. I had a quick look - TL;DR, DISubprogram attachment is omitted for member function declarations without definitions, this could possibly a bug or designed behaviour that I don't know about.

---

I thought at first it might be related to #70949 and the work-around there but that doesn't seem to be the case.

LLVM seems happy to generate DW_TAG_call_sites for tail calls (of non member functions), but I can't seem to convince it to produce call_sites for member functions at all (even ones that are not virtual or tail calls) in some simple examples, which seems weird...

struct S {
    int x;
    void member(int);
};

void nonmember(int);

void fun(S &s, int a) {
    s.member(a);  // member function call, no DW_TAG_call_site?
    nonmember(a); // tail call with DW_TAG_call_site
}

https://godbolt.org/z/cEG15qc7c

Ah - here in DwarfDebug.cpp CalleeSP is nullptr because the (declared but not defined) member function member doesn't get a DISubprogram attachment (though there is a DISubprogram node for it in the metadata, it's just not attached). This is different for the non-member-function nonmember, which does get a SP attachment. Adding a definition for the member function causes it to get a SP and subsequently a call site DIE.

I thought it could be related to -g[no-]omit-unreferenced-methods but that doesn't seem to affect it either way.

I'm not sure why the SP is omitted for member functions, or why the behaviour is different for non-member functions.

[jryans]

Thanks for taking a look @OCHyams.

If LLVM isn't generating call site DIEs at all in cases of declared-only member functions, does that mean such cases also do not have call site parameter info either? If so, that suggests there's also variable value coverage being lost here as well, as I believe that call site parameter DIEs are used to recover function entry values when present.

[OCHyams]

If LLVM isn't generating call site DIEs at all in cases of declared-only member functions, does that mean such cases also do not have call site parameter info either? If so, that suggests there's also variable value coverage being lost here as well, as I believe that call site parameter DIEs are used to recover function entry values when present.

I believe the spec leaves it open as to how entry_value values are recovered, but in practice yes that's right. The Sony debugger works that way and I'm sure others may too, and I believe when entry_values were added to LLVM call_site info came along with it as that was the intended method (could be hallucinating some history there though).