Clang generates wrong RTTI or Debug info?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Clang generates wrong RTTI or Debug info?

Richard Smith via cfe-dev
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



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang generates wrong RTTI or Debug info?

Richard Smith via cfe-dev
I've put the same question on stackoverflow: 

Maybe GDB is the problem, not Clang?


2018-01-25 21:03 GMT-08:00 Roman Popov <[hidden email]>:
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




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang generates wrong RTTI or Debug info?

Richard Smith via cfe-dev
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 <[hidden email]> wrote:
I've put the same question on stackoverflow: 

Maybe GDB is the problem, not Clang?


2018-01-25 21:03 GMT-08:00 Roman Popov <[hidden email]>:
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



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang generates wrong RTTI or Debug info?

Richard Smith via cfe-dev
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 <[hidden email]>:
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 <[hidden email]> wrote:
I've put the same question on stackoverflow: 

Maybe GDB is the problem, not Clang?


2018-01-25 21:03 GMT-08:00 Roman Popov <[hidden email]>:
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



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang generates wrong RTTI or Debug info?

Richard Smith via cfe-dev
*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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> wrote:
I've put the same question on stackoverflow: 

Maybe GDB is the problem, not Clang?


2018-01-25 21:03 GMT-08:00 Roman Popov <[hidden email]>:
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



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang generates wrong RTTI or Debug info?

Richard Smith 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 <[hidden email]>:
*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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> wrote:
I've put the same question on stackoverflow: 

Maybe GDB is the problem, not Clang?


2018-01-25 21:03 GMT-08:00 Roman Popov <[hidden email]>:
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



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang generates wrong RTTI or Debug info?

Richard Smith via cfe-dev


On Tue, Jan 30, 2018 at 9:43 AM Roman Popov <[hidden email]> 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 <[hidden email]>:
*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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> wrote:
I've put the same question on stackoverflow: 

Maybe GDB is the problem, not Clang?


2018-01-25 21:03 GMT-08:00 Roman Popov <[hidden email]>:
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



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev