<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 13, 2015 at 6:16 AM, <span dir="ltr"><<a href="mailto:Peter_Marshall@sn.scee.net" target="_blank">Peter_Marshall@sn.scee.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><font size="2" face="sans-serif">Hi Paul,</font>
<br>
<br><font size="2" face="sans-serif">Sorry for the delay, I've been out of
the office.</font>
<br>
<br><font size="2" face="sans-serif">I think this example shows that name
matching does not always work:</font>
<br>
<br><tt><font size="2">template<typename T> class A {</font></tt>
<br><tt><font size="2">public:</font></tt>
<br><tt><font size="2"> A(T val);</font></tt>
<br><tt><font size="2">private:</font></tt>
<br><tt><font size="2"> T x;</font></tt>
<br><tt><font size="2">}; </font></tt>
<br>
<br><tt><font size="2">struct B {</font></tt>
<br><tt><font size="2"> typedef float
MONKEY;</font></tt>
<br>
<br><tt><font size="2"> A<MONKEY>
*p;</font></tt>
<br><tt><font size="2">};</font></tt>
<br>
<br><tt><font size="2">B b;</font></tt>
<br>
<br><tt><font size="2">struct C {</font></tt>
<br><tt><font size="2"> typedef int MONKEY;</font></tt>
<br>
<br><tt><font size="2"> A<MONKEY>
*p;</font></tt>
<br><tt><font size="2">};</font></tt>
<br>
<br><tt><font size="2">C c;</font></tt>
<br>
<br><font size="2" face="sans-serif">This gives this DWARF:</font>
<br>
<br><tt><font size="2">+-0000003f DW_TAG_structure_type "B"</font></tt>
<br><tt><font size="2"> -DW_AT_name DW_FORM_strp "B"</font></tt>
<br><tt><font size="2"> +-00000047 DW_TAG_member "p"</font></tt>
<br><tt><font size="2"> -DW_AT_name DW_FORM_strp
"p"</font></tt>
<br><tt><font size="2"> +-DW_AT_type DW_FORM_ref4 0x00000054</font></tt>
<br><tt><font size="2"> +-00000054 DW_TAG_pointer_type
</font></tt>
<br><tt><font size="2"> +-DW_AT_type DW_FORM_ref4
0x00000059</font></tt>
<br><tt><font size="2"> +-00000059 DW_TAG_class_type
"A<MONKEY>"</font></tt>
<br><tt><font size="2"> -DW_AT_name
DW_FORM_strp "A<MONKEY>"</font></tt>
<br><tt><font size="2"> -DW_AT_declaration
DW_FORM_flag_present </font></tt>
<br>
<br><tt><font size="2">+-00000073 DW_TAG_structure_type "C"</font></tt>
<br><tt><font size="2"> -DW_AT_name DW_FORM_strp "C"</font></tt>
<br><tt><font size="2"> +-0000007b DW_TAG_member "p"</font></tt>
<br><tt><font size="2"> -DW_AT_name DW_FORM_strp
"p"</font></tt>
<br><tt><font size="2"> +-DW_AT_type DW_FORM_ref4 0x00000088</font></tt>
<br><tt><font size="2"> +-00000088 DW_TAG_pointer_type
</font></tt>
<br><tt><font size="2"> +-DW_AT_type DW_FORM_ref4
0x0000008d</font></tt>
<br><tt><font size="2"> +-0000008d DW_TAG_class_type
"A<MONKEY>"</font></tt>
<br><tt><font size="2"> -DW_AT_name
DW_FORM_strp "A<MONKEY>"</font></tt>
<br><tt><font size="2"> -DW_AT_declaration
DW_FORM_flag_present </font></tt>
<br></blockquote><div><br></div><div>That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be surprising if we used the typedef (or otherwise non-canonical) name in the class name):<br><br>(I've trimmed a few irrelevant attributes)<br><br></div><div><div><font face="monospace, monospace">0x0000001e: DW_TAG_variable [2] </font></div><div><font face="monospace, monospace"> DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000004c] = "b")</font></div><div><font face="monospace, monospace"> DW_AT_type [DW_FORM_ref4] (cu + 0x0033 => {0x00000033})</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x00000033: DW_TAG_structure_type [3] *</font></div><div><font face="monospace, monospace"> DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000059] = "B")</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x0000003b: DW_TAG_member [4] </font></div><div><font face="monospace, monospace"> DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000004e] = "p")</font></div><div><font face="monospace, monospace"> DW_AT_type [DW_FORM_ref4] (cu + 0x0048 => {0x00000048})</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x00000047: NULL</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x00000048: DW_TAG_pointer_type [5] </font></div><div><font face="monospace, monospace"> DW_AT_type [DW_FORM_ref4] (cu + 0x004d => {0x0000004d})</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x0000004d: DW_TAG_class_type [6] </font></div><div><font face="monospace, monospace"> DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000050] = "A<float>")</font></div><div><font face="monospace, monospace"> DW_AT_declaration [DW_FORM_flag_present] (true)</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x00000052: DW_TAG_variable [2] </font></div><div><font face="monospace, monospace"> DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000005b] = "c")</font></div><div><font face="monospace, monospace"> DW_AT_type [DW_FORM_ref4] (cu + 0x0067 => {0x00000067})</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x00000067: DW_TAG_structure_type [3] *</font></div><div><font face="monospace, monospace"> DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000064] = "C")</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x0000006f: DW_TAG_member [4] </font></div><div><font face="monospace, monospace"> DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000004e] = "p")</font></div><div><font face="monospace, monospace"> DW_AT_type [DW_FORM_ref4] (cu + 0x007c => {0x0000007c})</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x0000007b: NULL</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x0000007c: DW_TAG_pointer_type [5] </font></div><div><font face="monospace, monospace"> DW_AT_type [DW_FORM_ref4] (cu + 0x0081 => {0x00000081})</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">0x00000081: DW_TAG_class_type [6] </font></div><div><font face="monospace, monospace"> DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000005d] = "A<int>")</font></div><div><font face="monospace, monospace"> DW_AT_declaration [DW_FORM_flag_present] (true)</font></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br><font size="2" face="sans-serif">As there are no template parameters
for the forward declaration of either A<MONKEY></font>
<br><font size="2" face="sans-serif">they are indistinguishable.</font>
<br>
<br><font size="2" face="sans-serif">The reason we currently have no need
for the parameters in a template name is because we</font>
<br><font size="2" face="sans-serif">reconstruct template names from their
parameter tags. This allow the pretty printing to match</font>
<br><font size="2" face="sans-serif">the templates from the DWARF to match
our demangled symbols from the ELF symbol table.</font>
<br>
<br><font size="2" face="sans-serif">-Pete<br>
</font>
<br>
<br>
<br>
<br><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">"Robinson, Paul"
<<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif">David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>,
"Marshall, Peter" <<a href="mailto:Peter_Marshall@sn.scee.net" target="_blank">Peter_Marshall@sn.scee.net</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Cc:
</font><font size="1" face="sans-serif">"<a href="mailto:reviews%2BD14358%2Bpublic%2Bd3104135076f0a10@reviews.llvm.org" target="_blank">reviews+D14358+public+d3104135076f0a10@reviews.llvm.org</a>"
<<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>)" <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">10/11/2015 01:08</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">RE: [PATCH]
D14358: DWARF's forward decl of a template should have template parameters.</font>
<br>
<hr noshade><div><div class="h5">
<br>
<br>
<br><font size="2" color="#004080" face="Calibri">| </font><font size="3" face="Times New Roman">when/where/why
are types acquired from the mangled names of ELF symbols, rather than from
corresponding DWARF?</font>
<br><a name="1510134cf808aa9d__MailEndCompose"></a><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">Pete, can you help me out
here? David seems to want an ironclad case for not being able to
do something any other way, before he will let me put the template type
parameters on the declaration of a template instantiation. (He does
not deny that doing so would be valid DWARF, only that it can't possibly
be *useful* DWARF.)</font>
<br><font size="2" color="#004080" face="Calibri">Thanks,</font>
<br><font size="2" color="#004080" face="Calibri">--paulr</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" face="Tahoma"><b>From:</b> David Blaikie [</font><a href="mailto:dblaikie@gmail.com" target="_blank"><font size="2" face="Tahoma">mailto:dblaikie@gmail.com</font></a><font size="2" face="Tahoma">]
<b><br>
Sent:</b> Monday, November 09, 2015 4:08 PM<b><br>
To:</b> Robinson, Paul<b><br>
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>)<b><br>
Subject:</b> Re: [PATCH] D14358: DWARF's forward decl of a template should
have template parameters.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">On Mon, Nov 9, 2015 at 3:55 PM,
Robinson, Paul <</font><a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>Paul_Robinson@playstation.sony.com</u></font></a><font size="3" face="Times New Roman">>
wrote:</font>
<br><font size="2" color="#004080" face="Calibri">| </font><font size="3" face="Times New Roman">Why
is matching by name insufficient/not correct?</font>
<br><font size="2" color="#004080" face="Calibri">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.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">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?)</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="#004080" face="Calibri"> 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.</font>
<br><font size="2" color="#004080" face="Calibri">Having the template type
parameter means we have an unambiguous description of the type, and can
match it easily.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">| </font><font size="3" face="Times New Roman">including
unreferenced entities fails source fidelity</font>
<br><font size="2" color="#004080" face="Calibri">I'll assume you meant to
say _excluding_ unreferenced entities fails source fidelity,</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Indeed</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="#004080" face="Calibri">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.)</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">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?</font>
<br><font size="3" face="Times New Roman"> </font>
<br><a name="1510134cf808aa9d_150eead1526f60ef__MailEndCompose"></a><font size="2" color="#004080" face="Calibri">Omitting
template parameters however is not the same as omitting unreferenced entities,
because the template parameters *are* referenced—by the template instantiation
itself;</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Not quite sure I follow that logic.
It's quite possible to have unreferenced template parameters:<br>
<br>
template<typename><br>
void f() { }</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="#004080" face="Calibri">and, omitting them from the
source does not produce a valid program.</font>
<br><font size="3" face="Times New Roman"><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>
</font>
<br><font size="2" color="#004080" face="Calibri"> 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.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">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</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">Thanks,</font>
<br><font size="2" color="#004080" face="Calibri">--paulr</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" face="Tahoma"><b>From:</b> David Blaikie [mailto:</font><a href="mailto:dblaikie@gmail.com" target="_blank"><font size="2" color="blue" face="Tahoma"><u>dblaikie@gmail.com</u></font></a><font size="2" face="Tahoma">]
<b><br>
Sent:</b> Monday, November 09, 2015 1:46 PM</font>
<br><font size="3" face="Times New Roman"><b><br>
To:</b> Robinson, Paul<b><br>
Cc:</b> </font><a href="mailto:reviews%2BD14358%2Bpublic%2Bd3104135076f0a10@reviews.llvm.org" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>reviews+D14358+public+d3104135076f0a10@reviews.llvm.org</u></font></a><font size="3" face="Times New Roman">;
cfe-commits (</font><a href="mailto:cfe-commits@lists.llvm.org" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>cfe-commits@lists.llvm.org</u></font></a><font size="3" face="Times New Roman">)<b><br>
Subject:</b> Re: [PATCH] D14358: DWARF's forward decl of a template should
have template parameters.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">On Thu, Nov 5, 2015 at 11:05 AM,
Robinson, Paul <</font><a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>Paul_Robinson@playstation.sony.com</u></font></a><font size="3" face="Times New Roman">>
wrote:</font>
<br><font size="2" color="#004080" face="Calibri">| </font><a name="1510134cf808aa9d_150eead1526f60ef_150d90a05a633d3e__MailE"></a><font size="3" face="Times New Roman">What
was your primary motivation?</font>
<br><font size="2" color="#004080" face="Calibri">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.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Why is matching by name insufficient/not
correct?</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">| </font><font size="3" face="Times New Roman">maybe
it's possible to remangle the template using just the string name</font>
<br><font size="2" color="#004080" face="Calibri">I have no idea what you're
talking about here.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Looking at PR20455 you linked,
LLDB isn't finding the right function because of mangling:</font>
<br><font size="2" face="Courier New">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 </font>
<br><font size="3" face="Times New Roman">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>
</font>
<br><font size="2" color="#004080" face="Calibri">| | Choosing to emit a forward/incomplete
declaration in the first place fails source fidelity, </font>
<br><font size="3" face="Times New Roman">| How so?</font>
<br><font size="2" color="#004080" face="Calibri">When the source has a full
definition but Clang chooses to emit only the declaration, per CGDebugInfo.cpp/shouldOmitDefinition().</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">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;</font>
<br><font size="3" face="Times New Roman">foo<int> *f;</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="#004080" face="Calibri">--paulr</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" face="Tahoma"><b>From:</b> David Blaikie [mailto:</font><a href="mailto:dblaikie@gmail.com" target="_blank"><font size="2" color="blue" face="Tahoma"><u>dblaikie@gmail.com</u></font></a><font size="2" face="Tahoma">]
<b><br>
Sent:</b> Thursday, November 05, 2015 12:10 AM<b><br>
To:</b> Robinson, Paul<b><br>
Cc:</b> </font><a href="mailto:reviews%2BD14358%2Bpublic%2Bd3104135076f0a10@reviews.llvm.org" target="_blank"><font size="2" color="blue" face="Tahoma"><u>reviews+D14358+public+d3104135076f0a10@reviews.llvm.org</u></font></a><font size="2" face="Tahoma">;
cfe-commits (</font><a href="mailto:cfe-commits@lists.llvm.org" target="_blank"><font size="2" color="blue" face="Tahoma"><u>cfe-commits@lists.llvm.org</u></font></a><font size="2" face="Tahoma">)</font>
<br><font size="3" face="Times New Roman"><b><br>
Subject:</b> Re: [PATCH] D14358: DWARF's forward decl of a template should
have template parameters.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">On Wed, Nov 4, 2015 at 11:32 PM,
Robinson, Paul <</font><a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>Paul_Robinson@playstation.sony.com</u></font></a><font size="3" face="Times New Roman">>
wrote:</font>
<br><font size="2" color="#004080" face="Calibri">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.)</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">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?</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="#004080" face="Calibri"> Choosing to emit a
forward/incomplete declaration in the first place fails source fidelity,
</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">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)</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="#004080" face="Calibri">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.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Again, "correct" in DWARF
is a fairly nebulous concept.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="#004080" face="Calibri">--paulr</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">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.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">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)</font>
<br><font size="3" face="Times New Roman"> </font>
<br><a name="1510134cf808aa9d_150eead1526f60ef_150d90a05a633d3e_150d68"></a><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" face="Tahoma"><b>From:</b> David Blaikie [mailto:</font><a href="mailto:dblaikie@gmail.com" target="_blank"><font size="2" color="blue" face="Tahoma"><u>dblaikie@gmail.com</u></font></a><font size="2" face="Tahoma">]
<b><br>
Sent:</b> Wednesday, November 04, 2015 8:30 PM<b><br>
To:</b> </font><a href="mailto:reviews%2BD14358%2Bpublic%2Bd3104135076f0a10@reviews.llvm.org" target="_blank"><font size="2" color="blue" face="Tahoma"><u>reviews+D14358+public+d3104135076f0a10@reviews.llvm.org</u></font></a><font size="2" face="Tahoma">;
Robinson, Paul<b><br>
Subject:</b> Re: [PATCH] D14358: DWARF's forward decl of a template should
have template parameters.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">On Wed, Nov 4, 2015 at 5:53 PM,
Paul Robinson via cfe-commits <</font><a href="mailto:cfe-commits@lists.llvm.org" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>cfe-commits@lists.llvm.org</u></font></a><font size="3" face="Times New Roman">>
wrote:</font>
<br><font size="3" face="Times New Roman">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.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">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)).</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"><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.</font>
<br><font size="3" face="Times New Roman"><br>
</font><font size="3" color="blue" face="Times New Roman"><u><br>
</u></font><a href="http://reviews.llvm.org/D14358" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>http://reviews.llvm.org/D14358</u></font></a><font size="3" face="Times New Roman"><br>
<br>
<br>
<br>
_______________________________________________<br>
cfe-commits mailing list</font><font size="3" color="blue" face="Times New Roman"><u><br>
</u></font><a href="mailto:cfe-commits@lists.llvm.org" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>cfe-commits@lists.llvm.org</u></font></a><font size="3" color="blue" face="Times New Roman"><u><br>
</u></font><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</u></font></a>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="blue" face="sans-serif"><u><br>
</u></font><a></a></div></div><font size="2" face="Arial"><br>
**********************************************************************<br>
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify <a href="mailto:postmaster@scee.net" target="_blank">postmaster@scee.net</a><br>
This footnote also confirms that this email message has been checked for
all known viruses.<br>
Sony Computer Entertainment Europe Limited<br>
Registered Office: 10 Great Marlborough Street, London W1F 7LP, United
Kingdom<br>
Registered in England: 3277793<br>
**********************************************************************<br>
</font><font size="5" color="#008000" face="Webdings"><br>
P</font><font size="2" color="#008000" face="Arial"><b><i> Please consider
the environment before printing this e-mail</i></b></font>
</blockquote></div><br></div></div>