<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;}
/* 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.EmailStyle18
{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">Sony already has a private patch to not desugar type names in the DW_TAG_template_type_parameter name. IIRC we were finding that e.g. enums decayed to the underlying integer, which caused loss of useful information.<o:p></o:p></p>
<p class="MsoNormal">It kind of feels like D91311 is heading in a similar direction, and really ought to be using the preferred name in the parameter DIEs as well as the parent, for consistency.<o:p></o:p></p>
<p class="MsoNormal">Full disclosure, our debugger throws away the <template-parameters> in the parent name and reconstructs it from the parameter DIEs. So, what the compiler emits in the parent name is not interesting to our debugger. (And wasn’t there a
suggestion at some point to eliminate the <template-parameters> in the parent anyway? Because they could lead to an explosion of really long strings in the debug info, and those strings aren’t particularly user-friendly in the first place.)<o:p></o:p></p>
<p class="MsoNormal">--paulr<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> Sunday, August 8, 2021 6:40 PM<br>
<b>To:</b> Adrian Prantl <aprantl@apple.com>; Jonas Devlieghere <jdevlieghere@apple.com>; Robinson, Paul <paul.robinson@sony.com>; llvm-dev <llvm-dev@lists.llvm.org>; Reid Kleckner <rnk@google.com><br>
<b>Subject:</b> DWARF: Preferred names in templates<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Context: <a href="https://urldefense.com/v3/__https:/reviews.llvm.org/D91311__;!!JmoZiZGBv3RvKRSx!pJGuSYSXSZoUDceMyw0Nw0ln_aNgMLvUQXTNQ54R6hcXxGnb-_GXpIbn3-XyMLZ7ZQ$">
https://reviews.llvm.org/D91311</a><br>
<br>
So, this preferred name feature is designed to print names in a more user-centric way (eg: "std::vector<std::string, ...>" instead of "std::vector<std::basic_string<char, ...>, ...>".<br>
<br>
But this causes some divergence in the DWARF - the textual string says std::string, but the DW_TAG_template_type_parameter says std::basic_string<char... <br>
<br>
This isn't fundamentally problematic, kind of - there's a bunch of ways the full string name of a template won't match perfectly between producers and so consumers basically have to do some structural equivalence testing so far as I know. Though I'm not sure
exactly how much - they could do it by normalizing the string (with GCC and LLVM's default debug info don't include structural descriptions of template parameters on template declarations - so consumers would have to do string normalization, rather than discarding
the string argument representation and relying solely on the structural representation) in which case only a very advanced normalization that parsed std::string, did a lookup, resolved through typedefs and alias templates and then used the resulting string
would succeed here. I haven't tested gdb or lldb to see if/how they cope with this situation - but I would assume it's not good.<br>
<br>
So I think the only good solution here is to suppress use of preferred names when printing type names for debug info?<br>
<br>
It might be nice to have use of preferred names (& maybe take it further - I have a prototype patch - and use the preferred names/types in the structural representation as well (which presumably would break mixed clang/gcc debug info with most consumers, I'd
imagine - maybe it'd fall out OK for lldb when building ASTs)) under a flag? If you're building the codebase with one compiler and/or you just want to do more experimentation with the feature? Not sure it's worth it, but I think I have some reasonable attempt
at this... (there's one issue around cases of template declarations not carrying preferred names - discussed on the review itself)<br>
<br>
Thoughts, feelings, perspectives?<br>
<br>
- Dave<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>