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

[Pavel Labath via llvm-dev]

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.



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.

pl