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@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" <x...@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@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to