[lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

Mon Dec 18 11:59:34 PST 2017

Hi Anton and Jim,

What do you think about storing the mangled type name or the mangled vtable
symbol name somewhere in DWARF in the DW_AT_MIPS_linkage_name attribute? We
are already doing it for the mangled names of functions so extending it to
types shouldn't be too controversial.

Tamas

On Mon, 18 Dec 2017, 17:29 xgsa via lldb-dev, <lldb-dev at lists.llvm.org>
wrote:

> Thank you for clarification, Jim, you are right, I misunderstood a little
> bit what lldb actually does.
>
> It is not that the compiler can't be fixed, it's about the fact that
> relying on correspondence of mangled and demangled forms are not reliable
> enough, so we are looking for more robust alternatives. Moreover, I am not
> sure that such fuzzy matching could be done just basing on class name, so
> it will require reading more DIEs. Taking into account that, for instance,
> in our project there are quite many such types, it could noticeable slow
> down the debugger.
>
> Thus, I'd like to mention one more alternative and get your feedback, if
> possible. Actually, what is necessary is the correspondence of mangled and
> demangled vtable symbol. Possibly, it worth preparing a separate section
> during compilation (like e.g. apple_types), which would store this
> correspondence? It will work fast and be more reliable than the current
> approach, but certainly, will increase debug info size (however, cannot
> estimate which exact increase will be, e.g. in persent).
>
> What do you think? Which solution is preferable?
>
> Thanks,
> Anton.
>
> 15.12.2017, 23:34, "Jim Ingham" <jingham at apple.com>:
> > First off, just a technical point. lldb doesn't use RTTI to find dynamic
> types, and in fact works for projects like lldb & clang that turn off RTTI.
> It just uses the fact that the vtable symbol for an object demangles to:
> >
> > vtable for CLASSNAME
> >
> > That's not terribly important, but I just wanted to make sure people
> didn't think lldb was doing something fancy with RTTI... Note, gdb does (or
> at least used to do) dynamic detection the same way.
> >
> > If the compiler can't be fixed, then it seems like your solution [2] is
> what we'll have to try.
> >
> > As it works now, we get the CLASSNAME from the vtable symbol and look it
> up in the the list of types. That is pretty quick because the type names
> are indexed, so we can find it with a quick search in the index. Changing
> this over to a method where we do some additional string matching rather
> than just using the table's hashing is going to be a fair bit slower
> because you have to run over EVERY type name. But this might not be that
> bad. You would first look it up by exact CLASSNAME and only fall back on
> your fuzzy match if this fails, so most dynamic type lookups won't see any
> slowdown. And if you know the cases where you get into this problem you can
> probably further restrict when you need to do this work so you don't suffer
> this penalty for every lookup where we don't have debug info for the
> dynamic type. And you could keep a side-table of mangled-name -> DWARF
> name, and maybe a black-list for unfound names, so you only have to do this
> once.
> >
> > This estimation is based on the assumption that you can do your work
> just on the type names, without having to get more type information out of
> the DWARF for each candidate match. A solution that relies on realizing
> every class in lldb so you can get more information out of the type
> information to help with the match will defeat all our attempts at lazy
> DWARF reading. This can cause quite long delays in big programs. So I would
> be much more worried about a solution that requires this kind of work.
> Again, if you can reject most potential candidates by looking at the name,
> and only have to realize a few likely types, the approach might not be that
> slow.
> >
> > Jim
> >
> >>  On Dec 15, 2017, at 7:11 AM, xgsa via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >>
> >>  Sorry, I probably shouldn't have used HTML for that message. Converted
> to plain text.
> >>
> >>  -------- Original message --------
> >>  15.12.2017, 18:01, "xgsa" <xgsa at yandex.ru>:
> >>
> >>  Hi,
> >>
> >>  I am working on issue that in C++ program for some complex cases with
> templates showing dynamic type based on RTTI in lldb doesn't work properly.
> Consider the following example:
> >>  enum class TagType : bool
> >>  {
> >>     Tag1
> >>  };
> >>
> >>  struct I
> >>  {
> >>     virtual ~I() = default;
> >>  };
> >>
> >>  template <TagType Tag>
> >>  struct Impl : public I
> >>  {
> >>  private:
> >>     int v = 123;
> >>  };
> >>
> >>  int main(int argc, const char * argv[]) {
> >>     Impl<TagType::Tag1> impl;
> >>     I& i = impl;
> >>     return 0;
> >>  }
> >>
> >>  For this example clang generates type name "Impl<TagType::Tag1>" in
> DWARF and "__ZTS4ImplIL7TagType0EE" when mangling symbols (which lldb
> demangles to Impl<(TagType)0>). Thus when in
> ItaniumABILanguageRuntime::GetTypeInfoFromVTableAddress() lldb tries to
> resolve the type, it is unable to find it. More cases and the detailed
> description why lldb fails here can be found in this clang review, which
> tries to fix this in clang [1].
> >>
> >>  However, during the discussion around this review [2], it was pointed
> out that DWARF names are expected to be close to sources, which clang does
> perfectly, whereas mangling algorithm is strictly defined. Thus matching
> them on equality could sometimes fail. The suggested idea in [2] was to
> implement more semantically aware matching. There is enough information in
> the DWARF to semantically match "Impl<(TagType)0>)" with
> "Impl<TagType::Tag1>", as enum TagType is in the DWARF, and the enumerator
> Tag1 is present with its value 0. I have some concerns about the
> performance of such solution, but I'd like to know your opinion about this
> idea in general. In case it is approved, I'm going to work on implementing
> it.
> >>
> >>  So what do you think about type names inequality and the suggested
> solution?
> >
> >>  [1] - https://reviews.llvm.org/D39622
> >>  [2] -
> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171211/212859.html
> >>
> >>  Thank you,
> >>  Anton.
> >>  _______________________________________________
> >>  lldb-dev mailing list
> >>  lldb-dev at lists.llvm.org
> >>  http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20171218/1e87a227/attachment.html>