<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 3:55 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div><span class="">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">|
</span>Why is matching by name insufficient/not correct?<u></u><u></u></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I'm told we look at the mangled names in the ELF symbol table, demangle them, and look in the DWARF for the corresponding types.</span></p></div></div></blockquote><div><br></div><div>Not quite sure I follow that - when/where/why are types acquired from the mangled names of ELF symbols, rather than from corresponding DWARF? (eg: the DWARF describing the type of a function's parameter?)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Now, the mangled name (for
predefined types in particular) provides a type description, not the name-as-emitted-by-Clang, and in fact the same type can have more than one name ('const int' and 'int const' for a trivial example). The name Clang provides in the DWARF does not necessarily
match the name produced by the demangler; this makes name-matching way more trouble than you'd think. We're not interested in teaching the debugger how to parse template instantiation names.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Having the template type parameter means we have an unambiguous description of the type, and can match it easily.<u></u><u></u></span></p><span class="">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">|
</span>including unreferenced entities fails source fidelity<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
</span><p class="MsoNormal"><a name="150eead1526f60ef__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I'll assume you meant to say _excluding_ unreferenced entities fails source fidelity,</span></a></p></div></div></blockquote><div><br></div><div>Indeed</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><a name="150eead1526f60ef__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> which is quite true, but there is a valid engineering
tradeoff in that what the DWARF actually contains (or not, in the case of, say, unused function declarations or unreferenced class contents) represents one possible valid source that could have produced the same object. (I'm curious why an unreferenced formal
parameter of a function still gets described, if this is your argument for omitting template parameters.)</span></a></p></div></div></blockquote><div><br></div><div>Omitting parameters would make the function description unusable for callers, for example - so there's some value in describing them so that a debugger can evaluate expressions involving calls to the function, yes?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><a name="150eead1526f60ef__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Omitting template parameters however is not the same as omitting unreferenced entities, because the template parameters *are* referenced—by the template instantiation
itself;</span></p></div></div></blockquote><div><br></div><div>Not quite sure I follow that logic. It's quite possible to have unreferenced template parameters:<br><br> template<typename><br> void f() { }<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> and, omitting them from the source does not produce a valid program.</span></p></div></div></blockquote><div><br>Omitting the names still produces a valid program - though I'm not quite sure which omission you're referring to. (& even if we omit the names, we still describe the parameters - as we do for unused/unnamed function parameters)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Now, one of the 3 debuggers Clang explicitly supports (i.e. gdb) seems not to mind that they're missing, but the other two would benefit from having these things, and I would really
like to have Clang produce these things.</span></p></div></div></blockquote><div><br></div><div>It sounds like the LLDB bug you cited is being treated as an LLDB bug, not a Clang one, for now. So I'm not sure it's relevant to justifying Clang changes just yet, unless they come back & suggest that they don't actually have enough information to implement the features they would like to implement.<br><br>& equally I'd like to understand the features that you'd like to build with this info that can't be built without it (as a minimum: features that GDB doesn't support, since any features GDB does support seem to be implementable with the current info Clang and GCC emit)<br><br>- David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></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 #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> David Blaikie [mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>]
<br>
<b>Sent:</b> Monday, November 09, 2015 1:46 PM</span></p><div><div class="h5"><br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> <a href="mailto:reviews%2BD14358%2Bpublic%2Bd3104135076f0a10@reviews.llvm.org" target="_blank">reviews+D14358+public+d3104135076f0a10@reviews.llvm.org</a>; cfe-commits (<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>)<br>
<b>Subject:</b> Re: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.<u></u><u></u></div></div><p></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Thu, Nov 5, 2015 at 11:05 AM, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">|
</span><a name="150eead1526f60ef_150d90a05a633d3e__MailEndCompose">What was your primary motivation?</a><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">A similar concern to PR20455 from our own debugger. It much helps matching up the forward declaration
and definition to have the parameters properly specified.</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Why is matching by name insufficient/not correct?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">|
</span>maybe it's possible to remangle the template using just the string name<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I have no idea what you're talking about here.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Looking at PR20455 you linked, LLDB isn't finding the right function because of mangling:<br>
<br>
<u></u><u></u></p>
<pre><span style="color:black">call to a function 'basic_string<char, char_traits<char> >::operator[](int) const' ('_ZNK12basic_stringIc17char_traits<char>EixEi') that is not present in the target <u></u><u></u></span></pre>
</div>
<div>
<p class="MsoNormal">It hasn't created the correct mangled name of operator[] - what I was saying is it might be possible to parse the template parameter from the pretty name, and use that to produce the mangled name. It /looks/ like GDB can manage this. Maybe
only because we also include the mangled name of the member function? Not sure.<br>
<u></u><u></u></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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">| | Choosing to emit a forward/incomplete declaration in the first place fails source fidelity,
</span><u></u><u></u></p>
<p class="MsoNormal">| How so?<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">When the source has a full definition but Clang chooses to emit only the declaration, per CGDebugInfo.cpp/shouldOmitDefinition().</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Sure, in the same way that including unreferenced entities fails source fidelity - all tradeoffs to reduce debug info size.<br>
<br>
Though the behavior is visible in a simpler example that doesn't have that failing (& if your change goes in, the test case should probably be simplified like this):<br>
<br>
template<typename T> struct foo;<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">foo<int> *f;<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></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 #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> David Blaikie [mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, November 05, 2015 12:10 AM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> <a href="mailto:reviews%2BD14358%2Bpublic%2Bd3104135076f0a10@reviews.llvm.org" target="_blank">
reviews+D14358+public+d3104135076f0a10@reviews.llvm.org</a>; cfe-commits (<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>)</span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.<u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Wed, Nov 4, 2015 at 11:32 PM, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Would citing PR20455 help? It wasn't actually my primary motivation but it's not too far off. Having
the template parameters there lets you know what's going on in the DWARF, without having to fetch and parse the name string of every struct you come across. Actually I'm not sure parsing the name string is unambiguous either; each parameter is either a typename,
or an expression, but without the parameter DIEs you don't know which, a-priori. (What does <foo> mean? Depends on whether you think it should be a type name or a value; you can't tell, syntactically, you have to do some lookups. Ah, but if you had the parameter
DIEs, you would Just Know.)</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">For LLDB's needs, I'm not sure it's sufficient either - but I wouldn't mind an answer before we use it as the basis for this change (it sounds like maybe it's possible to remangle
the template using just the string name, rather than needing an explicit representation of the parameters)<br>
<br>
What was your primary motivation?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Choosing to emit a forward/incomplete declaration in the first place fails source fidelity,
</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">How so? You might have only a template declaration (template<typename T> struct foo; foo<int> *f;) or you may've only instantiated the declaration (the C++ language requires you
to instantiate or avoid instantiating certain things in certain places, so in some contexts you /only/ have an instantiated declaration, not a definition)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">but it is a practical engineering tradeoff of compile/link performance against utility; and, after
all, the source *could* have been written that way, with no semantic difference. But, if we're going to emit a white-lie incomplete declaration, we should do so correctly.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Again, "correct" in DWARF is a fairly nebulous concept.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">P.S. We should talk about this forward-declaration tactic wrt LTO sometime. I have a case where
a nested class got forward-declared; it's entirely conceivable that the outer class with the inner forward-declared class would end up being picked by LTO, leaving the user with no debug info for the inner class contents.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I believe this Just Works(tm). The things that can vary per-insntance of a type (implicit special members, member template implicit specializations, and nested types*) are not added
to the type's child list, but they reference the child as their parent. So they continue to apply no matter which instance of the type is picked for uniquing (because of the name-based referencing, so the nested type definition just says "my parent is _Zfoo"
and whatever _Zfoo we end up picking in the LTO linking/metadata deduplication will serve that role just fine)<br>
<br>
* we could just do a better job of modelling nested types (& other non-globally scoped types) in a way that more closely models the source by emitting a declaration where they were declared, and a definition where they are defined (with the usual DW_AT_specification
to wire them up)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><a name="150eead1526f60ef_150d90a05a633d3e_150d68fb48e97b27__MailE"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></a><u></u><u></u></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 #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> David Blaikie [mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, November 04, 2015 8:30 PM<br>
<b>To:</b> <a href="mailto:reviews%2BD14358%2Bpublic%2Bd3104135076f0a10@reviews.llvm.org" target="_blank">
reviews+D14358+public+d3104135076f0a10@reviews.llvm.org</a>; Robinson, Paul<br>
<b>Subject:</b> Re: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Wed, Nov 4, 2015 at 5:53 PM, Paul Robinson via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">probinson added a comment.<br>
<br>
GCC 4.8.4 on Linux doesn't produce these, but DWARF 4 section 5.5.8 says a class template instantiation is just like the equivalent non-template class entry, with the exception of the template parameter entries. I read that as meaning an incomplete description
(i.e. with DW_AT_declaration) lets you omit all the other children, but not the template parameters.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">As usual, I think it's pretty hard to argue that DWARF /requires/ anything (permissive & all that). And I'm not sure that having these is particularly valuable/useful - what use
do you have in mind for them?<br>
<br>
Wouldn't hurt to have some size info about the cost here, though I don't imagine it's massive, it does open us up to emitting a whole slew of new types (the types the template is instantiated with, and anything that depends on - breaking/avoiding type edges
can, in my experience, be quite beneficial (I described an example of this in my lightning talk last week)).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal"><br>
I don't think omitting the template DIEs was an intentional optimization, in the sense of being a decision separate from deciding to emit the incomplete/forward declaration in the first place. They were just omitted because we were omitting everything, but
everything turns out to be non-compliant.<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<a href="http://reviews.llvm.org/D14358" target="_blank">http://reviews.llvm.org/D14358</a><br>
<br>
<br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>
</div>
</blockquote></div><br></div></div>