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@lists.llvm.org <mailto:lldb-dev@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" <jing...@apple.com
<mailto:jing...@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@lists.llvm.org <mailto: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
<mailto: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 <mailto:lldb-dev@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
