[PATCH] D76336: [DWARF] Emit DW_AT_call_pc for tail calls

[Djordje Todorovic via Phabricator via llvm-commits]

djtodoro added a comment.

@vsk Thanks for working on this!

> @vsk wrote:
> @dblaikie @djtodoro I'd prefer to leave things as they are, but am also open to disabling DIFlagAllCallsDescribed for -gdwarf-4 + -ggdb until entry values get re-enabled by default, let me know what you think.

I'd keep it as is, since I am preparing the patch for enabling the entry values by default, since the patch was not the cause of the issue reported.

> @dblaikie wrote:
> why is this only relevant in optimized builds?

I think the main benefit of the call-site information is using it together with call-site-parameters, used for computing the actual value of parameter, even the location of the parameter was not provided (optimized-out). That improves debugging user experience when debugging optimized code. In addition, in the case of tail calls, the call_site debug info is used for printing artificial call frames for the tail calls (and tail calls are typical to optimized code?).



================
Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:873
       const MCSymbol *PCAddr =
           (IsTail && !tuneForGDB())
               ? nullptr
----------------
vsk wrote:
> djtodoro wrote:
> > Looks like the `dwarf::DW_AT_call_return_pc` is enough for GDB to distinguish that even for tail calls. Can we do the same for LLDB and avoid the `call_pc`?
> > 
> > 
> I don't think that would be valid DWARF. The return pc for a tail call isn't given by the address of the instruction after after the tail-calling branch.
> 
> Are you sure GDB uses DW_AT_call_return_pc to figure out the address where the tail call was made?
GCC generates the `low_pc` for DWARF 4 (actually GNU extension) and for the DWARF 5 DW_AT_call_return_pc for the call_site TAGs describing the tail calls.
That is the address after the jump-like instruction for a tail call.

GDB understands that info and prints the artificial frames (the test case from the D76337):
//gcc  -g -O2 tail.c -o gcc-tail-example//
  ...
  (gdb) r
  Starting program: gcc-tail-example
  Breakpoint 1, sink () at tail.c:4
  4         x++;
  (gdb) bt
  #0  sink () at tail.c:4
  #1  0x00000000004004a6 in func3 () at tail.c:9
  #2  0x00000000004004b7 in func2 () at tail.c:13
  #3  0x00000000004004d6 in func1 () at tail.c:18
  #4  0x0000000000400367 in main () at tail.c:22
  ...

  //GDB version 8.3.5//
  //GCC version 4.9.3//

The same happens when using the latest LLVM Trunk (with the D73534 applied), since the DWARF 4 + GDB generates the same DWARF as GCC for the example.
//clang -g -O2 tail.c -o tail-example//
  ...
  (gdb) r
  Starting program: tail-example
  Breakpoint 1, sink () at tail.c:4
  4         x++;
  (gdb) bt
  #0  sink () at tail.c:4
  #1  0x0000000000401149 in func3 () at tail.c:9      // the DW_AT_low_pc  is 0x401149 from the corresponding call_site
  #2  0x0000000000401156 in func2 () at tail.c:13
  #3  0x0000000000401169 in func1 () at tail.c:18
  #4  0x0000000000401176 in main () at tail.c:22
  ...



================
Comment at: llvm/test/DebugInfo/MIR/X86/call-site-gnu-vs-dwarf5-attrs.mir:17
 #
 # extern void fn();
 # extern void fn2(int x);
----------------
vsk wrote:
> djtodoro wrote:
> > GCC produces this:
> >    <2><9a>: Abbrev Number: 9 (DW_TAG_GNU_call_site)
> >       <9b>   DW_AT_low_pc      : 0x23
> >       <a3>   DW_AT_GNU_tail_call: 1
> >       <a3>   DW_AT_abstract_origin: <0xd4>
> Is the DW_AT_low_pc the address of the tail-calling branch instruction, or is it the address of the next instruction?
As I mentioned above, it is the address **after** the tail-call instruction.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76336/new/

https://reviews.llvm.org/D76336