[llvm-dev] [lldb-dev] Adding DWARF5 accelerator table support to llvm
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 15 12:13:54 PDT 2018
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
> gc> know if the DWARF knows about that flag. If we do a flag, it would be
> gc> if it were mandatory on all classes to indicate support for the flag.
> 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
> pr> you've found all the different templates. If the count is zero,
> 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
> 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> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev