Call site info: Register offsets ignored when emitting DW_AT_call_target

[OCHyams]

clang version 18.0.0 (bc41b0a)
Target: x86_64-unknown-linux-gnu

In the reproducer below, there's an indirect call through b's vtable to virtual function v. The vtable address is loaded into RAX, and as v is the second vtable entry we get the code call qword ptr [rax + 8].

Despite this, clang emits a call site entry with DW_AT_call_target expression DW_OP_reg0. In this instance the expression should be DW_OP_breg0+8.

DW_AT_call_target       (DW_OP_reg0 RAX)

$ cat test.cpp

struct Base {
  virtual int zz() { return x; }
  [[clang::noinline]]
  virtual int v() { return zz(); }
  int x;
};
struct Child: public Base {
  [[clang::noinline]]
  virtual int v() { return x * 2; }
  int x;
};

[[clang::noinline]]
[[clang::disable_tail_calls]]
int foo(Base* b) {
  return b->v();
}

$ clang test.cpp -O2 -g -c -o test.o
$ llvm-dwarfdump test.o --name foo --show-children

0x00000027: DW_TAG_subprogram
              DW_AT_name ("foo")
              ...


0x00000037:   DW_TAG_formal_parameter
                ...

0x00000040:   DW_TAG_call_site
                DW_AT_call_target    (DW_OP_reg0 RAX)
                DW_AT_call_return_pc (0x0000000000000007)

0x00000044:     DW_TAG_call_site_parameter
                  ...

0x0000004b:     NULL

0x0000004c:   NULL

$ llvm-objdump --disassemble-symbols=_Z3fooP4Base test.o --x86-asm-syntax=intel

0000000000000000 <_Z3fooP4Base>:
       0: 50                           push rax
       1: 48 8b 07                     mov  rax, qword ptr [rdi]
       4: ff 50 08                     call qword ptr [rax + 0x8]
       7: 59                           pop  rcx
       8: c3                           ret

N.B. DW_AT_call_target should not be used if there are volatile registers involved, see
#70948.

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Orlando Cazalet-Hyams (OCHyams)

clang version 18.0.0 (bc41b0a) Target: x86_64-unknown-linux-gnu

In the reproducer below, there's an indirect call through b's vtable to virtual function v. The vtable address is loaded into RAX, and as v is the second vtable entry we get the code call qword ptr [rax + 8].

Despite this, clang emits a call site entry with DW_AT_call_target expression DW_OP_reg0. In this instance the expression should be DW_OP_breg0+8.

DW_AT_call_target       (DW_OP_reg0 RAX)

$ cat test.cpp

struct Base {
  virtual int zz() { return x; }
  [[clang::noinline]]
  virtual int v() { return zz(); }
  int x;
};
struct Child: public Base {
  [[clang::noinline]]
  virtual int v() { return x * 2; }
  int x;
};

[[clang::noinline]]
[[clang::disable_tail_calls]]
int foo(Base* b) {
  return b->v();
}

$ clang test.cpp -O2 -g -c -o test.o
$ llvm-dwarfdump test.o --name foo --show-children

0x00000027: DW_TAG_subprogram
              DW_AT_name ("foo")
              ...


0x00000037:   DW_TAG_formal_parameter
                ...

0x00000040:   DW_TAG_call_site
                DW_AT_call_target    (DW_OP_reg0 RAX)
                DW_AT_call_return_pc (0x0000000000000007)

0x00000044:     DW_TAG_call_site_parameter
                  ...

0x0000004b:     NULL

0x0000004c:   NULL

$ llvm-objdump --disassemble-symbols=_Z3fooP4Base test.o --x86-asm-syntax=intel

0000000000000000 <_Z3fooP4Base>:
       0: 50                           push rax
       1: 48 8b 07                     mov  rax, qword ptr [rdi]
       4: ff 50 08                     call qword ptr [rax + 0x8]
       7: 59                           pop  rcx
       8: c3                           ret

N.B. DW_AT_call_target should not be used if there are volatile registers involved, see
#70948.

[thejh]

I think the main issue here is that DwarfDebug::constructCallSiteEntryDIEs() does not distinguish between CALL64r and CALL64m machine instructions:

• for CALL64r, CalleeOp will be the operand containing the destination of the call
• for CALL64m, CalleeOp will be the operand containing the address of the destination of the call

[OCHyams]

Thanks for the additional info there. Looks like the DW_TAG_call_site is now omitted (perhaps one of your recent fixes?), which is better than getting it wrong. I suppose we should keep this open as it should still be possible to represent the offset memory locations, IIUC.

[thejh]

Yes, my commit da6424c ("[DebugInfo][DWARF] Don't emit bogus DW_AT_call_target for complex calls (#151378)") causes the DW_TAG_call_site to be omitted in your example, since LLVM doesn't currently have code to emit such debuginfo for call [rax] (it only knows how to do it right for call rax).