[cfe-dev] Clang generates wrong RTTI or Debug info?

[Roman Popov via cfe-dev]

Unfortunately it's out of my control : I need to introspect arbitrary user
code. So I will just exclude Clang support for now and stay on g++.
So I have no simple workaround: GDB has no built-in C++ frontend, so it
can't by itself prove that types in RTTI and Debuginfo are the same .

Originally I thought that dynamic type identification in debugger is a
reliable mechanism. But now I'm thinking that I have to write exhaustive
unit-test, to make sure that at least g++/gdb pair works reliably.

- Roman



2018-01-30 9:33 GMT-08:00 David Blaikie <dblaikie at gmail.com>:

> *nod* One workaround would be to avoid dynamic class templates with enum
> parameters - use integer parameters instead. Though admittedly this might
> be a rather difficult/annoying workaround if they're used pervasively (or
> impossible if these APIs are outside your control).
>
> - Dave
>
> On Tue, Jan 30, 2018 at 9:16 AM Roman Popov <ripopov at gmail.com> wrote:
>
>> So this is a well-known Clang bug. And it affects both GDB and LLDB...
>>
>> Hope it will be fixed soon.
>> In my case it is a complete show-stopper: I use GDB python scripting for
>> C++ introspection and Verilog/VHDL code-generation. And it is part of my
>> build flow.
>>
>>
>> -Roman
>>
>> 2018-01-29 11:38 GMT-08:00 David Blaikie <dblaikie at gmail.com>:
>>
>>> This came up not too long ago: https://reviews.llvm.org/D39622
>>>
>>> I'm leaning towards accepting at least some uniform naming scheme
>>> (rather than, say "enum X { Y = 0, Z = 0 };" as a template parameter with
>>> foo<Z> named as foo<Y> and foo<(X)1> as foo<1> - maybe they should all be,
>>> as GCC does, foo<(X)N>).
>>>
>>> It's a slightly awkward thing to require that the GDB demangler and
>>> Clang's naming match letter-for-letter (& I think GDB's matching is a bit
>>> fuzzier than that - I seem to recall seeing it handle some differences in
>>> whitespace, maybe in parentheses/casts?).
>>>
>>> - Dave
>>>
>>> On Fri, Jan 26, 2018 at 1:28 PM Roman Popov via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>>> I've put the same question on stackoverflow:
>>>> https://stackoverflow.com/questions/48469750/debugging-
>>>> clang-generated-rtti-code-with-gdb
>>>>
>>>> Maybe GDB is the problem, not Clang?
>>>>
>>>>
>>>> 2018-01-25 21:03 GMT-08:00 Roman Popov <ripopov at gmail.com>:
>>>>
>>>>> Hello,
>>>>>
>>>>> I'm using Clang++ together with GDB. I've noticed that for some
>>>>> polymorphic classes GDB does not shows correct dynamic type.  After some
>>>>> investigation it turned out that Clang puts different typenames in DWARF
>>>>> and RTTI :
>>>>>
>>>>> I have a template class:
>>>>>
>>>>> template< class T, sc_writer_policy POL>
>>>>> class sc_signal : public sc_object
>>>>>
>>>>> where sc_writer_policy is an enum:
>>>>>
>>>>> enum sc_writer_policy
>>>>> {
>>>>>   SC_ONE_WRITER        = 0,
>>>>>   SC_MANY_WRITERS      = 1,
>>>>>   SC_UNCHECKED_WRITERS = 3
>>>>> };
>>>>>
>>>>>
>>>>> When I debug polymorphic objects of this class I got GDB errors like
>>>>> this:
>>>>>
>>>>> warning: RTTI symbol not found for class 'sc_core::sc_signal<int,
>>>>> (sc_core::sc_writer_policy)0>'
>>>>>
>>>>>
>>>>> The source of the problem is that it type name seems to be saved
>>>>> differently in RTTI and Debug info.
>>>>>
>>>>> From GDB:
>>>>> (gdb) info types sc_signal<int
>>>>> All types matching regular expression "sc_signal<int":
>>>>>
>>>>> *sc_core::sc_signal<int, sc_core::SC_ONE_WRITER>*
>>>>>
>>>>> Using RTTI:
>>>>>
>>>>> cout << typeid(*obj).name();
>>>>> N7sc_core9sc_signalIiLNS_16*sc_writer_policyE0*EEE
>>>>>
>>>>> So in RTTI we have mangled sc_core::sc_signal<int,
>>>>> (sc_core::sc_writer_policy)0>
>>>>>
>>>>>
>>>>> Is it possible to make Clang emitting same type-name in both cases?
>>>>>
>>>>>
>>>>> Originally I've discovered this issue with Clang++5.0.  Just tried
>>>>> with Clang++6.0 and it is still there.
>>>>> g++ 5.4 and g++7.0 both work fine, (sc_core::sc_signal<int,
>>>>> (sc_core::sc_writer_policy)0> is generated in both cases)
>>>>>
>>>>> Thanks,
>>>>> Roman
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180130/740f206b/attachment.html>