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_16sc_writer_policyE0EEE
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
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 named as foo 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?).
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
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).
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.
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.