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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D76336#1929994 <https://reviews.llvm.org/D76336#1929994>, @vsk wrote:

> 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.


Right, an ELF measurement is what I was interested in, owing to the different relocations & .rela.debug_addr is especially significant to my use case involving split DWARF and compressed DWARF, so some of the largest remaining content is debug_addr relocations.

>> 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.

But they haven't had addresses on them?

Hmm, that doesn't seem to reproduce with a simple example:

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

Doesn't have any call_site (compiled with clang with -g -c for linux/x86 or darwin/x86).

> 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.

Sure, happy to leave things as-is.


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

https://reviews.llvm.org/D76336