| Why is matching by name insufficient/not correct?
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. 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.
Having the template type parameter means we have an unambiguous description of
the type, and can match it easily.
| including unreferenced entities fails source fidelity
I'll assume you meant to say _excluding_ unreferenced entities fails source
fidelity, 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.)
Omitting template parameters however is not the same as omitting unreferenced
entities, because the template parameters *are* referenced—by the template
instantiation itself; and, omitting them from the source does not produce a
valid program. 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.
Thanks,
--paulr
From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Monday, November 09, 2015 1:46 PM
To: Robinson, Paul
Cc: reviews+d14358+public+d3104135076f0...@reviews.llvm.org; cfe-commits
(cfe-commits@lists.llvm.org)
Subject: Re: [PATCH] D14358: DWARF's forward decl of a template should have
template parameters.
On Thu, Nov 5, 2015 at 11:05 AM, Robinson, Paul
<paul_robin...@playstation.sony.com<mailto:paul_robin...@playstation.sony.com>>
wrote:
| What was your primary motivation?
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.
Why is matching by name insufficient/not correct?
| maybe it's possible to remangle the template using just the string name
I have no idea what you're talking about here.
Looking at PR20455 you linked, LLDB isn't finding the right function because of
mangling:
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
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.
| | Choosing to emit a forward/incomplete declaration in the first place fails
source fidelity,
| How so?
When the source has a full definition but Clang chooses to emit only the
declaration, per CGDebugInfo.cpp/shouldOmitDefinition().
Sure, in the same way that including unreferenced entities fails source
fidelity - all tradeoffs to reduce debug info size.
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):
template<typename T> struct foo;
foo<int> *f;
--paulr
From: David Blaikie [mailto:dblai...@gmail.com<mailto:dblai...@gmail.com>]
Sent: Thursday, November 05, 2015 12:10 AM
To: Robinson, Paul
Cc:
reviews+d14358+public+d3104135076f0...@reviews.llvm.org<mailto:reviews%2bd14358%2bpublic%2bd3104135076f0...@reviews.llvm.org>;
cfe-commits (cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>)
Subject: Re: [PATCH] D14358: DWARF's forward decl of a template should have
template parameters.
On Wed, Nov 4, 2015 at 11:32 PM, Robinson, Paul
<paul_robin...@playstation.sony.com<mailto:paul_robin...@playstation.sony.com>>
wrote:
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.)
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)
What was your primary motivation?
Choosing to emit a forward/incomplete declaration in the first place fails
source fidelity,
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)
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.
Again, "correct" in DWARF is a fairly nebulous concept.
--paulr
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.
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)
* 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)
From: David Blaikie [mailto:dblai...@gmail.com<mailto:dblai...@gmail.com>]
Sent: Wednesday, November 04, 2015 8:30 PM
To:
reviews+d14358+public+d3104135076f0...@reviews.llvm.org<mailto:reviews%2bd14358%2bpublic%2bd3104135076f0...@reviews.llvm.org>;
Robinson, Paul
Subject: Re: [PATCH] D14358: DWARF's forward decl of a template should have
template parameters.
On Wed, Nov 4, 2015 at 5:53 PM, Paul Robinson via cfe-commits
<cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>> wrote:
probinson added a comment.
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.
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?
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)).
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.
http://reviews.llvm.org/D14358
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
