[llvm-dev] [lldb-dev] Adding DWARF5 accelerator table support to llvm

[David Blaikie via llvm-dev]

How do you handle name lookup for nested classes? They have the same
problem (they don't appear in all definitions) - don't appear in all
descriptions of the outer/parent class. (in theory we could ensure there's
always at least a declaration of the nested class - but we don't even do
that if the nested class is unused)

Is it just the case that Clang doesn't mind you adding a new nested class
but it does mind you adding a new member function template? If so, maybe we
could change Clang to support adding new member function templates instead
of extending DWARF?

On Fri, Jun 15, 2018 at 11:59 AM <paul.robinson at sony.com> wrote:

> gc> Solution #1 would cause us to dig through all definitions of all C++
> gc> classes all the time when parsing DWARF to check if definitions of
> gc> the classes had template methods. And we would need to find the class
> gc> that has the most template methods. This would cause us to parse much
> gc> more of the debug info all of the time and cause increased memory
> gc> consumption and performance regressions.
>
> pr> It would be cheap to put a flag on the class DIE that tells you there
> pr> are template methods to go look for.  Then you incur the cost only
> pr> when necessary.  And the accelerator table makes it fast to find the
> pr> other class descriptions.
>
> gc> That is a fine solution. But we still run into the problem where we
> don't
> gc> know if the DWARF knows about that flag. If we do a flag, it would be
> nice
> gc> if it were mandatory on all classes to indicate support for the flag.
> But
> gc> this would be a fine solution and not hard to implement.
>
> pr> So what you really want is not a flag, but a count, so you can tell
> when
> pr> you've found all the different templates.  If the count is zero,
> there's
> pr> nothing to look for.  If the count is two, you look around at all the
> pr> various definitions of the class until you find two different
> templates,
> pr> then you stop.  If there's no count attribute, your producer doesn't
> pr> know you want this information and you do it the hard way.  Or, we've
> pr> invented a way to describe the templates directly in the class.
> pr>
> pr> How's that?
>
> gc> that would work fine.
>
> I filed PR37816 to track this idea.
>
> The other ideas:
>
>  - accelerator to point to the actual instantiations
>  - emitting template definitions not just instantiations
>
> would be trickier to define and harder to implement correctly.
> I won't say they can't be done, but somebody else would have to do
> the heavy lifting here, unless it turns out that our debugger folks
> like the idea.
>
> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180615/d978dfe0/attachment.html>