<div dir="ltr">Cool - good to know!<br><br>(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)<br><br>eg: extern int i; template<int *> void f1() { } int main() { f1<&i>(); }<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 14, 2021 at 7:00 PM <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_4039599520572615812WordSection1">
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal">--paulr<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> <br>
<b>Sent:</b> Monday, June 7, 2021 6:49 PM<br>
<b>To:</b> Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>>; Jonas Devlieghere <<a href="mailto:jdevlieghere@apple.com" target="_blank">jdevlieghere@apple.com</a>>; Henderson, James <<a href="mailto:James.Henderson@sony.com" target="_blank">James.Henderson@sony.com</a>>; Caroline Tice <<a href="mailto:cmtice@google.com" target="_blank">cmtice@google.com</a>>; Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>><br>
<b>Subject:</b> Re: [DWARF] using simplified template names<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Jun 7, 2021 at 3:00 PM <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<u></u><u></u></p>
</div>
<div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Fully expanded names of template instantiations can become impressively large, yeah.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">The DWARF Wiki’s Best Practices page
<a href="https://urldefense.com/v3/__http:/wiki.dwarfstd.org/index.php?title=Best_Practices__;!!JmoZiZGBv3RvKRSx!o9KwsGo1xoYiOWlyAmsw893vZHwDXk2f3wKhdQsPeQFfIaGRCVQ_agzVb77WsSaubQ$" target="_blank">
http://wiki.dwarfstd.org/index.php?title=Best_Practices</a> 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.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><br>
Ah, good to know - and yeah, the asymmetry between omitting namespace qualifiers but including parameters is noteworthy.<br>
 <u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">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.
<span style="font-family:"Segoe UI Emoji",sans-serif">😊</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><br>
Ah, fascinating/good to know!<br>
<br>
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.<br>
 <u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"> Oh, is there any consequence for deduplication in LTO?  Isn’t that name-based?<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:9.6pt"><br>
Should be OK - that's based on the fully mangled/linkage name of the type, which would be untouched by this.<br>
<br>
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)<br>
<br>
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).<br>
<br>
- Dave<br>
<br>
<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>

</blockquote></div>