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

Vedant Kumar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 18 15:46:41 PDT 2020


vsk marked 2 inline comments as done.
vsk added a comment.

In D76336#1928056 <https://reviews.llvm.org/D76336#1928056>, @dblaikie wrote:

> (general caveat: this should be committed as separate patches - between llvm and llvm-dsymutil (much like llvm-dwarfdump and llvm codegen are usually committed separately) - but yeah, it's nice to see it all together for review))


Sounds good, I'll split this up before committing.

> Do you happen to have numbers for, say, clang, on the growth of object size because of this - specifically I'd be interested in the growth of the .rela.debug_addr section in a DWARFv5 build.

I looked at the size impact on a Darwin -gdwarf-4 stage2 clang build. The aggregate size of .o's post-patch grows 0.006% (8367046264 bytes -> 8367544576 bytes, a 486KB increase). Tail calls make up ~5% of all calls (in clang at least), so this is in line with what was measured in D72489 <https://reviews.llvm.org/D72489>. In D72489 <https://reviews.llvm.org/D72489>, I added a relocation to every non-tail call site entry, which increased the aggregate .o size by 0.04% (~3MB).

I don't think linker support for dwarf5 is mature enough on Darwin for me to measure. Perhaps that measurement wouldn't be very useful, as ELF relocations are different.

> Did I understand correctly from previous discussions that the goal was to have call_sites for /every/ call, at some point? (I'm concerned that'll be a /lot/ of addresses)

Yes. When tuning for lldb, we've been emitting call sites for every call for some time now.

Hm :(. Digging through the history, I see that I accidentally turned on DIFlagAllCallsDescribed when targeting -gdwarf-4 + GDB in D69743 <https://reviews.llvm.org/D69743> (November 2019). This was done prematurely, I apologize for this. It should not have happened until the entry values feature got enabled by default. I've checked in test coverage for -gdwarf-4 + -ggdb to clang/test/CodeGenCXX/dbg-info-all-calls-described.cpp in 47622efc <https://reviews.llvm.org/rG47622efc6f01532ef1c23490f516efb9081827f8>.

@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 suppose another question, I guess - how many more call_sites is this than currently/without this patch?

This patch doesn't change the number of call site entries (DW_TAG_call_site), it just adds relocations to ~3-5% of those entries.



================
Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:873
       const MCSymbol *PCAddr =
           (IsTail && !tuneForGDB())
               ? nullptr
----------------
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?


================
Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1789
+  // TODO: Add support for targets with delay slots.
+  if (!NoDebug && SP->areAllCallsDescribed() && MI->isCall() &&
+      !MI->hasDelaySlot()) {
----------------
djtodoro wrote:
> Should we use the `isCandidateForCallSiteEntry()` instead?
Yes, thanks!


================
Comment at: llvm/test/DebugInfo/MIR/X86/call-site-gnu-vs-dwarf5-attrs.mir:17
 #
 # extern void fn();
 # extern void fn2(int x);
----------------
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?


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

https://reviews.llvm.org/D76336





More information about the llvm-commits mailing list