<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<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.<o:p></o:p></p>
<p class="MsoNormal">--paulr<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> David Blaikie <dblaikie@gmail.com> <br>
<b>Sent:</b> Monday, June 7, 2021 6:49 PM<br>
<b>To:</b> Robinson, Paul <paul.robinson@sony.com><br>
<b>Cc:</b> llvm-dev <llvm-dev@lists.llvm.org>; Adrian Prantl <aprantl@apple.com>; Jonas Devlieghere <jdevlieghere@apple.com>; Henderson, James <James.Henderson@sony.com>; Caroline Tice <cmtice@google.com>; Eric Christopher <echristo@gmail.com><br>
<b>Subject:</b> Re: [DWARF] using simplified template names<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Jun 7, 2021 at 3:00 PM <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Fully expanded names of template instantiations can become impressively large, yeah.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></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>
<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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><o:p></o:p></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>
<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> Oh, is there any consequence for deduplication in LTO? Isn’t that name-based?<o:p></o:p></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>
<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>