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

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>

Here is result of experiment:

(Original size , with DW_AT_linkage_name for composites, % increase)
clang-7.0 1926574256 1952846192   1.4%
clang-tidy 1220980360 1238498112   1.4%
llvm-mt  7404728 7525328 1.6 %
std::cout << "hello world!" 21552 22080  2.4 %

IMO, not that big price for reliable dynamic type identification (Full
disclosure: I need depend on this feature, since I'm writing Python pretty
printers for GDB )

-Roman

2018-03-02 18:12 GMT-08:00 Roman Popov <ripopov at gmail.com>:
> 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/6e5b84ce/attachment.html>

Is that putting linkage name on every class that has an identifier in the
IR?

I'm guessing that's not necessary/excessive - only RTTI types would need
it? Perhaps without changing Clang, LLVM could be changed to only attach
the linkage name to a type that it was emitting the virtual parts of a
class?

Also: The original example with "template<auto T>" (I don't
know what that
feature is called, sorry) does present some problems that probably need to
be fixed regardless (two different instantiations having the same name's
clearly a problem, for example - and I might be convinced that the enum
case should change so it can produce a consistent type even in the face of
a forward-declared enum (with an explicit underlying type specified), for
example) - but even with those things fixed, I agree it's still not a great
idea to have debuggers need to match mangled names to pretty printed names.

On Fri, Mar 2, 2018 at 7:55 PM Roman Popov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Here is result of experiment:
>
> (Original size , with DW_AT_linkage_name for composites, % increase)
> clang-7.0 1926574256 1952846192   1.4%
> clang-tidy 1220980360 1238498112   1.4%
> llvm-mt  7404728 7525328 1.6 %
> std::cout << "hello world!" 21552 22080  2.4 %
>
> IMO, not that big price for reliable dynamic type identification (Full
> disclosure: I need depend on this feature, since I'm writing Python
pretty
> printers for GDB )
>
> -Roman
>
> 2018-03-02 18:12 GMT-08:00 Roman Popov <ripopov at gmail.com>:
>
>> 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
>>>
>>>
>>
> _______________________________________________
> 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/20180304/940bd515/attachment.html>