[llvm-dev] [DWARF] using simplified template names

[David Blaikie via llvm-dev]

Cool - good to know!

(out of curiosity, any idea what the Sony debugger does for pointer
template parameters? At least GCC doesn't seem to be able to reconstruct
those back into strings (you'd basically have to symbolize the address
value of the parameter (GCC doesn't even encode this value, so it's not
surprising GDB doesn't try to do anything when it's present)) - so I'll
probably implement this under a flag but not include (ie: use the current
full textual encoding) any template with a pointer template parameter)

eg: extern int i; template<int *> void f1() { } int main() { f1<&i>(); }

On Mon, Jun 14, 2021 at 7:00 PM <paul.robinson at sony.com> wrote:

> I’ve heard back from the Sony debugger folks, and dropping the <params>
> from the parent DIE’s name will have no bad effect on us.  We rebuild the
> <params> from the children, and we don’t currently make use of the index.
> If this tactic goes under an option, we’d definitely like to have that set
> by default under sce-tuning to get the space savings.
>
> --paulr
>
>
>
>
>
> *From:* David Blaikie <dblaikie at gmail.com>
> *Sent:* Monday, June 7, 2021 6:49 PM
> *To:* Robinson, Paul <paul.robinson at sony.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>; Adrian Prantl <aprantl at apple.com>;
> Jonas Devlieghere <jdevlieghere at apple.com>; Henderson, James <
> James.Henderson at sony.com>; Caroline Tice <cmtice at google.com>; Eric
> Christopher <echristo at gmail.com>
> *Subject:* Re: [DWARF] using simplified template names
>
>
>
> On Mon, Jun 7, 2021 at 3:00 PM <paul.robinson at sony.com> wrote:
>
> Fully expanded names of template instantiations can become impressively
> large, yeah.
>
>
>
> The DWARF Wiki’s Best Practices page
> http://wiki.dwarfstd.org/index.php?title=Best_Practices
> <https://urldefense.com/v3/__http:/wiki.dwarfstd.org/index.php?title=Best_Practices__;!!JmoZiZGBv3RvKRSx!o9KwsGo1xoYiOWlyAmsw893vZHwDXk2f3wKhdQsPeQFfIaGRCVQ_agzVb77WsSaubQ$>
> recommends including a canonical form of the template parameters in the
> DW_AT_name attribute.  I don’t know that I agree; it talks about omitting
> qualifiers (namespaces, containing classes) because those can be
> reconstructed from the DIE hierarchy, but the same argument can be made for
> template parameters (the difference being that qualifiers come from higher
> up the tree, while template parameters come from farther down).  The DRY
> principle would seem to apply here.
>
>
> Ah, good to know - and yeah, the asymmetry between omitting namespace
> qualifiers but including parameters is noteworthy.
>
>
> I’ll verify with our debugger team, but I’m confident that dropping the
> <params> from the type name will not affect Sony, as our debugger looks at
> the template-parameter children already (that’s why we have that turned on
> by default for sce tuning).  LLDB seems to be the odd debugger out, here,
> and we have some control over that. 😊
>
>
> Ah, fascinating/good to know!
>
> So even if /maybe/ we wouldn't want to do this for GDB tuning (I'd be a
> bit hesitant to diverge that much from GCC's defaults even if it seems to
> work (more testing to see how broadly it works) you might be interested in
> this being the default for SCE? That'd be good to do. I guess if we fix
> LLDB might be able to switch the defaults there too.
>
>
>  Oh, is there any consequence for deduplication in LTO?  Isn’t that
> name-based?
>
>
> Should be OK - that's based on the fully mangled/linkage name of the type,
> which would be untouched by this.
>
> One quirk is that we probably can't do this for templates with pointer
> non-type template parameters (I haven't tested non-pointer non-type
> template parameters (such as integers, chars, etc) but I'd hope GDB can
> handle that and that would provide at least some "proof of concept") since
> they don't have an easy unambiguous stringification - even though you can
> only use a named variable/function/etc (ie: can't use an array offset, or
> other computed address) - neither GCC nor Clang encode that string, but
> instead encode the address (well, GCC doesn't even encode the address - so
> that debug info doesn't adversely affect code generation by causing the
> symbol to be linked in when it's otherwise unreferenced by the actual code)
> & so coming up with an unambiguous/consistent string to use in building the
> name would be a bit much. GDB doesn't seem to handle that situation. (says
> "UNKNOWN" or similar for the parameter, thus creating ambiguity when
> matching against others, etc)
>
> The other area I'd be unsure about would be indexes - gdb index and
> DWARFv5 debug_names. We'll be indexing the linkage/mangled name (hmm, we
> don't do the linkage name for types - only for functions), and the simple
> name - but, as you point out - we were skipping namespaces already, so it's
> not like looking up "foo<int>" was unambiguous anyway - so they'll be a bit
> more ambiguous after this change. Some consumer performance impact - they'd
> have to search through more duplicates (take std::vector - now a consumer
> will have to go look at every CU that has any vector instantiation, whereas
> previously they were probably able to only look at the vector<int>
> instantiating CUs (& any nonstd::vector<int> out there as well) for
> instance).
>
> - Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210614/d5b0e9f9/attachment.html>