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

Greg Clayton via llvm-dev
Mon, 18 Jun 2018 16:17:03 -0000

> On Jun 15, 2018, at 1:48 PM, Pavel Labath <labath at google.com>
wrote:
>
> On Fri, 15 Jun 2018 at 20:14, David Blaikie <dblaikie at gmail.com>
wrote:
>>
>> 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?
>
>
> I was thinking about the same thing. It seems to me that this could be
> viewed as a deficiency of our implementation of dwarf parsing. (It's a
> pretty understandable deficiency, given that we are based on clang
> (compiler), and it thinks of the types in the same way as C++ does --
> incomplete; or complete with template members and all). However, these
> template member functions should not impact anything "important"
in
> the class (data member layout, vtables, ...) so one could conceivably
> have an implementation which allows member addition on the fly. And in
> this case the existing accelerator tables would work perfectly -- we
> would get a query "does this class have method X", we would look
at
> the accel table, and it would point us straight to X. However, I have
> no idea how hard would it be to fit this scheme into the existing
> clang/lldb design.

For a little background on how the DWARF parsing works. When anything has a type
"class A" in LLDB (variable, method in class A, etc), we first create
a forward declaration to class A in the clang AST. Each symbol file installs
itself as an external AST source that can complete any types when requested.
This uses the functionality that mimics each symbol file being a precompiled
header. Since we have an external AST source, clang can ask for the type to be
completed at any time (just like clang does with PCH files), which will call
back into the external AST source and cause the type to be completed.

In LLDB, we have 3 distinct states of a type: forward declaration to type,
completed type, the type we need for layout. If a variable has a type
"class A*", then when displaying this variable in the output of
"frame var", we don't need to know the full definition of class A.
If the user expands a type in say an IDE variable view or types an expression
that results in a class A instance or reference, we will get the complete
version of the type. When we are making other types that include class A through
inheritance or as a member variable, we may or may not need get the full
definition for class A. For example if we have a "class A* m_a_ptr;"
member variable, we don't need to know about A since we only need to know
what type we need in order to layout the type which is a pointer here. If we
inherit from class A or have a "class A m_a;" then the layout type
needed here would be the full type. So we are very careful to only expand the
type when and if needed in LLDB.

That being said we currently only have two versions of the type as far as clang
know: forward and complete. I think this is how clang expects things to be as
well. So the above approach could work as long as we can teach clang to ask the
external AST source about addition names when doing method lookups, but that
will take some clang modifications that will probably only need to be enabled in
debugger mode. Also if we did add this ability, we will want to limit it to
classes that have templated functions we don't want to always ask a class we
have completed to continually look for things when the user types an expression
wrong like "a.this_method_never_will_exist_in_a()". Maybe that is ok
though.

If we are able to make the above approach work, then there will need to be an
additional fix where we would need to teach AST importer to be able to compare
two classes and ignore any template methods when doing the compare when in
debugger mode only. We might have two shared libraries that each have a class A,
one with one specialized function and one with another, and when one or both of
those get imported into the expression or target AST, they would need to merge
the type correctly when importing it. Right now if there are two class trying be
to imported at the same decl context layer the import will fail if the class
exists at the same level and isn't exactly the same.

So quite a bit of clang work if we want to make this work.

Each symbol file installs itself as an external AST source so if we wanted to
add the template member functions on the fly, hopefully we would get a request
that says in the DeclContext "class A" what is "Foo" if you
type something like:

A a;
(lldb) a.Foo<int>()

But I am not sure what clang will do if it already thinks it knows the
definition for class A, so we might need to teach clang, that in debugger mode
only, check the external AST source if there is one to see.


>
>
> That said, having DWARF be able to represent the template member
> functions in an abstract way also sounds like nice thing to have from
> a debug info format.

Yes, that would be great, but will require DWARF changes and is much more long
term.