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

[David Blaikie via cfe-commits]

On Wed, Sep 27, 2017 at 11:50 AM Paul Robinson via Phabricator <
reviews at reviews.llvm.org> wrote:

> probinson added a comment.
>
> In https://reviews.llvm.org/D14358#882445, @dblaikie wrote:
>
> > > I would prefer to eliminate the `<params>` from the instance name as
> well, because our debugger reconstructs a name more to its liking from the
> parameter children.  However, IIUC the name with params is used for
> deduplication in LTO, so that is probably not such a good idea. :-)
> >
> > Though you have this out of tree? How do you cope with LTO there?
>
>
> We discovered that we had to keep them in the name for LTO.
>
> > I've not fully refreshed myself on the previous conversations - but it
> looks like my thought was that this state proposed here is
> weird/inconsistent: The parameters are already in the name, so adding them
> in the DIEs seems redundant. If the parameters weren't in the name then
> this change might make more sense.
>
> Our debugger throws away the params in the name, and relies on the
> children.  The names as rendered in DWARF by Clang are not textually
> consistent with names as rendered by the demangler.  Our debugger uses the
> children to construct names that are consistent with how the demangler
> works.  Then it can match up type names returned by the demangler to type
> names it has constructed.  Assuming I am not misunderstanding our debugger
> guys again, but that's my recollection.
>
> I believe we have talked previously about using a different scheme for
> deduplication that doesn't depend (or not so much) on the names.  If we had
> that, we could eliminate params from the name, and save probably a
> noticeable chunk of space in the string section.  I haven't tried to
> measure that, though.  But we have to have the children in place before we
> can experiment with other deduplication schemes.
>

Fair enough - yeah, I would agree with Adrian that this probably isn't a
driver flag (at least not yet), though. Either only driven by the debugger
tuning (though perhaps we had some position that debugger tuning wouldn't
ever be the only way to access functionality, only change defaults) or
additionally a cc1 flag. Haven't thought about the name.


>
> There is also the pedantic point that DWARF doesn't say these child
> entries are optional, or omitted for forward declarations.  I know gcc
> doesn't (or didn't, anyway; what I have locally is gcc 5.4) but gcc is not
> the arbiter of what constitutes conforming DWARF.
>
>
> https://reviews.llvm.org/D14358
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170927/79770739/attachment.html>