llvm dev - Mar 2018 - Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

Hi all,

As you may know modern C++ debuggers (GDB and LLDB) support dynamic type
identification for polymorphic objects, by utilizing C++ RTTI.
Unfortunately this feature does not work with Clang and GDB >= 7.x .  The
last compiler that worked well was G++ 6.x

I've asked about this issue both on GDB and LLDB maillists. Unfortunately
it's hard or impossible to fix it on debugger side.
The problem is that compilers do not emit linkage name of type to debug
information, and so debuggers can't link RTTI with DW_TAG_*_types reliably.

Consider example:

////////////////////////////////////////////////////////////////
enum class EN{ONE,TWO};

template<auto x>
struct foo { virtual ~foo() {} };

foo<11u> fu;
foo<11> fi;
foo<EN::ONE> fe;
////////////////////////////////////////////////////////////////

Clang will put following names to RTTI:

3fooILi11EE         ->      foo<11>
3fooILj11EE         ->      foo<11u>
3fooIL2EN0EE        ->      foo<(EN)0>

And to debuginfo it will emit 3 DW_TAG_structure_types with
following DW_AT_names:

DW_AT_name: foo<11>
DW_AT_name: foo<11>
DW_AT_name: foo<EN::ONE>

Currently what debugger has to do is to demangle RTTI name and try to match
it to DW_AT_name attribute to find type. As you can see it does not work
for any of 3 examples.

I've asked about the problem on G++ maillist, and one of the proposed
solutions is to emit DW_AT_linkage_name for types.

Can this solution be also implemented in LLVM?

I've checked LLVM docs and found out that LLVM generates DWARF from LLVM
metadata.  LLVM metadata for types already contains linkage name in
"identifier" field: https://llvm.org/docs/LangRef.html#dicompositetype
So LLVM itself can identify types by name, the only remaining issue is to
emit it to debuginfo.  That should be two lines of code in
: DwarfUnit::constructTypeDIE, something like:

StringRef LinkageName = CTy->getIdentifier();
addString(Buffer, dwarf::DW_AT_linkage_name, LinkageName);



Thanks,
Roman
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180302/10e773f8/attachment.html>

> Currently what debugger has to do is to demangle RTTI name and try to
> match it to DW_AT_name attribute to find type. As you can see it does
> not work for any of 3 examples.
>
> I've asked about the problem on G++ maillist, and one of the proposed
> solutions is to emit DW_AT_linkage_name for types. 
>
> Can this solution be also implemented in LLVM? 
It could, but mangled names can be very long and we need to consider
whether the additional size cost is worth it under various conditions.
For example, does this type matching work when a program is compiled
with `-fno-rtti`?  (Clang itself is compiled this way by default.)
Thanks,
--paulr

Mangled names can be long indeed, but pretty-printed types are also long. I
can evaluate effect on size on clang codebase itself.

If you disable RTTI, than obviously you can't use it. So if RTTI is
disabled, we can disable mangled names in DWARF. Clang is compiled without
standard C++ RTTI because it has it's own RTTI. In general, however, many
libraries use standard RTTI.



2018-03-02 17:43 GMT-08:00 <paul.robinson at sony.com>:
> > Currently what debugger has to do is to demangle RTTI name and try to
> > match it to DW_AT_name attribute to find type. As you can see it does
> > not work for any of 3 examples.
> >
> > I've asked about the problem on G++ maillist, and one of the
proposed
> > solutions is to emit DW_AT_linkage_name for types.
> >
> > Can this solution be also implemented in LLVM?
>
> It could, but mangled names can be very long and we need to consider
> whether the additional size cost is worth it under various conditions.
> For example, does this type matching work when a program is compiled
> with `-fno-rtti`?  (Clang itself is compiled this way by default.)
> Thanks,
> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180302/ef5a1d7b/attachment.html>

On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> As you may know modern C++ debuggers (GDB and LLDB) support dynamic type
> identification for polymorphic objects, by utilizing C++ RTTI.
> Unfortunately this feature does not work with Clang and GDB >= 7.x . 
The
> last compiler that worked well was G++ 6.x
>
> I've asked about this issue both on GDB and LLDB maillists.
Unfortunately
> it's hard or impossible to fix it on debugger side.
>
Errr, i posited a solution on the gdb mailing list that i haven't seen shot
down so far, that doesn't require linkage names, it only requires one new
attribute that is a DW_FORM_ref, and very cheap.

I also wrote the RTTI code for GDB :)

Currently what debugger has to do is to demangle RTTI name and try to
match
> it to DW_AT_name attribute to find type. As you can see it does not work
> for any of 3 examples.
>
> I've asked about the problem on G++ maillist, and one of the proposed
> solutions is to emit DW_AT_linkage_name for types.
>
> Can this solution be also implemented in LLVM?
>
Please, no.

This is completely unneeded and wastes a huge amount of space.

As you can see from the replies to my solution on the gdb mailing list, it
is used by other languages (rust, for example) *anyway*, so we might as
well use it for C++ too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180303/b86ba382/attachment.html>

To explain to others who didn't follow that thread:

GDB currently does something amazingly stupid (and has since i wrote it) to
find the RTTI type.  There were no other good options at the type.

What it does is find the vtable for the object, find the symbol that
represents the vtable, demangle it, , chops off "vtable for", and
tries to
find the symbol for the string that results.

If you don't emit the linkage name, there are cases it won't find it,
because this is a really dumb way of trying to find the answer :)

It also wont' find it depending on what demangler you use, etc.

Here's a more direct way:
For each vtable DIE, link to the concrete type it represents.

Now you just go from vtable object to concrete type with no string lookup,
which is faster, doesnt' require linkage names, doesn't depend on
demanglers matching, etc.

As an added bonus: This is what Tom Tromey already added to Rust to do
this. So it's even been implemented before.






On Sat, Mar 3, 2018 at 8:20 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
>
>
> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> As you may know modern C++ debuggers (GDB and LLDB) support dynamic
type
>> identification for polymorphic objects, by utilizing C++ RTTI.
>> Unfortunately this feature does not work with Clang and GDB >= 7.x .
The
>> last compiler that worked well was G++ 6.x
>>
>> I've asked about this issue both on GDB and LLDB maillists.
Unfortunately
>> it's hard or impossible to fix it on debugger side.
>>
>
> Errr, i posited a solution on the gdb mailing list that i haven't seen
> shot down so far, that doesn't require linkage names, it only requires
one
> new attribute that is a DW_FORM_ref, and very cheap.
>
> I also wrote the RTTI code for GDB :)
>
> Currently what debugger has to do is to demangle RTTI name and try to
>> match it to DW_AT_name attribute to find type. As you can see it does
not
>> work for any of 3 examples.
>>
>> I've asked about the problem on G++ maillist, and one of the
proposed
>> solutions is to emit DW_AT_linkage_name for types.
>>
>> Can this solution be also implemented in LLVM?
>>
>
> Please, no.
>
> This is completely unneeded and wastes a huge amount of space.
>
> As you can see from the replies to my solution on the gdb mailing list, it
> is used by other languages (rust, for example) *anyway*, so we might as
> well use it for C++ too.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180303/8971a555/attachment.html>

On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> As you may know modern C++ debuggers (GDB and LLDB) support dynamic
type
>> identification for polymorphic objects, by utilizing C++ RTTI.
>> Unfortunately this feature does not work with Clang and GDB >= 7.x .
The
>> last compiler that worked well was G++ 6.x
>>
>> I've asked about this issue both on GDB and LLDB maillists.
Unfortunately
>> it's hard or impossible to fix it on debugger side.
>>
>
> Errr, i posited a solution on the gdb mailing list that i haven't seen
> shot down so far, that doesn't require linkage names, it only requires
one
> new attribute that is a DW_FORM_ref, and very cheap.
>
FWIW, for C++ at least, neither Clang nor GCC (6.3) produce any DWARF to
describe the vtable itself (they describe the vtable pointer inside the
struct, but not the constant vtable array) - so it'll be a bit more than
one attribute, but the bytes describe the vtable (as a global variable? Do
we give it a name? (if so, we're back to paying that cost)) first, then to
add the reference from that to the type.

& I'm not sure what Apple would do or anyone else that has libraries
without debug info shipped & users have to debug them (this is what broke
-fno-standalone-debug for Apple - their driver API which ships without
debug info of its own, has strong vtables in it).

I can go into more detail there - but there are certainly some annoying
edge cases/questions I have here :/

>
> I also wrote the RTTI code for GDB :)
>
> Currently what debugger has to do is to demangle RTTI name and try to
>> match it to DW_AT_name attribute to find type. As you can see it does
not
>> work for any of 3 examples.
>>
>> I've asked about the problem on G++ maillist, and one of the
proposed
>> solutions is to emit DW_AT_linkage_name for types.
>>
>> Can this solution be also implemented in LLVM?
>>
>
> Please, no.
>
> This is completely unneeded and wastes a huge amount of space.
>
> As you can see from the replies to my solution on the gdb mailing list, it
> is used by other languages (rust, for example) *anyway*, so we might as
> well use it for C++ too.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180305/15c750c6/attachment-0001.html>