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

[David Blaikie via cfe-dev]

On Tue, Jan 30, 2018 at 9:43 AM Roman Popov <ripopov at gmail.com> wrote:

> 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 .
>

GDB already does some fuzzy matching, I think - I believe it can cope with
some explicit casts, 'u' suffixes, whitespace differences, etc. So it could
in theory cope with this too - by looking up the enumeration type &
translating the enumerator name to its value, etc. But yeah, unlikely GDB
would be too interested in implementing that, and that's understandable.


> 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.
>

Never hurts to test - though I'd guess the g++/gdb pair is pretty solid on
this.


>
> - 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/e3669bb9/attachment.html>