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

[xgsa via lldb-dev]

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.