On Thu, Nov 5, 2015 at 11:05 AM, Robinson, Paul <
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]
> *Sent:* Thursday, November 05, 2015 12:10 AM
> *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 Wed, Nov 4, 2015 at 11:32 PM, Robinson, Paul <
> 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]
> *Sent:* Wednesday, November 04, 2015 8:30 PM
> *To:* reviews+d14358+public+d3104135076f0...@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> 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
> 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
