[PATCH] D14358: DWARF's forward decl of a template should have template parameters.

[David Blaikie via cfe-commits]

On Wed, Nov 4, 2015 at 11:32 PM, Robinson, Paul <
Paul_Robinson at 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:dblaikie at gmail.com]
> *Sent:* Wednesday, November 04, 2015 8:30 PM
> *To:* reviews+D14358+public+d3104135076f0a10 at 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 at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151105/37fe753e/attachment.html>