<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 30, 2018 at 9:43 AM Roman Popov <<a href="mailto:ripopov@gmail.com">ripopov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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++.<div>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 . <br></div></div></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div></div></blockquote><div><br>Never hurts to test - though I'd guess the g++/gdb pair is pretty solid on this.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div></div><div dir="ltr"><div><div><br></div><div>- Roman<br><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-30 9:33 GMT-08:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">*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).<br><br>- Dave<div><div class="m_-5739311422719536797h5"><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 30, 2018 at 9:16 AM Roman Popov <<a href="mailto:ripopov@gmail.com" target="_blank">ripopov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So this is a well-known Clang bug. And it affects both GDB and LLDB...<div><br></div><div>Hope it will be fixed soon. </div><div>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.</div></div><div dir="ltr"><div><br></div><div><br></div><div>-Roman</div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-29 11:38 GMT-08:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This came up not too long ago: <a href="https://reviews.llvm.org/D39622" target="_blank">https://reviews.llvm.org/D39622</a><br><br>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>).<br><br>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?).<br><br>- Dave<br><br><div class="gmail_quote"><div><div class="m_-5739311422719536797m_6844929681512539941m_5776183679627629583m_2689312758853811973h5"><div dir="ltr">On Fri, Jan 26, 2018 at 1:28 PM Roman Popov via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-5739311422719536797m_6844929681512539941m_5776183679627629583m_2689312758853811973h5"><div dir="ltr">I've put the same question on stackoverflow: <div><a href="https://stackoverflow.com/questions/48469750/debugging-clang-generated-rtti-code-with-gdb" target="_blank">https://stackoverflow.com/questions/48469750/debugging-clang-generated-rtti-code-with-gdb</a></div><div><br></div><div>Maybe GDB is the problem, not Clang?</div><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-25 21:03 GMT-08:00 Roman Popov <span dir="ltr"><<a href="mailto:ripopov@gmail.com" target="_blank">ripopov@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>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 :</div><div><br></div><div>I have a template class:</div><div><br></div><div><div><font face="monospace, monospace" size="1">template< class T, sc_writer_policy POL></font></div><div><font face="monospace, monospace" size="1">class sc_signal : public sc_object</font></div></div><div><br></div><div>where sc_writer_policy is an enum:</div><div><div><br></div><div><font face="monospace, monospace" size="1">enum sc_writer_policy</font></div><div><font face="monospace, monospace" size="1">{</font></div><div><font face="monospace, monospace" size="1"> SC_ONE_WRITER = 0, </font></div><div><font face="monospace, monospace" size="1"> SC_MANY_WRITERS = 1, </font></div><div><font face="monospace, monospace" size="1"> SC_UNCHECKED_WRITERS = 3</font></div><div><font face="monospace, monospace" size="1">};</font></div></div><div><br></div><div><br></div><div>When I debug polymorphic objects of this class I got GDB errors like this:</div><div><br></div><div><div><font face="monospace, monospace" size="1">warning: RTTI symbol not found for class 'sc_core::sc_signal<int, (sc_core::sc_writer_policy)0>'</font></div></div><div><br></div><div><br></div><div>The source of the problem is that it type name seems to be saved differently in RTTI and Debug info. </div><div><br></div><div>From GDB:</div><div><div><font face="monospace, monospace" size="1">(gdb) info types sc_signal<int</font></div><div><font face="monospace, monospace" size="1">All types matching regular expression "sc_signal<int":</font></div><div><b><font face="monospace, monospace" size="1">sc_core::sc_signal<int, sc_core::SC_ONE_WRITER><br></font></b></div></div><div><br></div><div><div>Using RTTI:</div><div><br></div><div><font face="monospace, monospace" size="1">cout << typeid(*obj).name();</font></div></div><div><div><font face="monospace, monospace" size="1">N7sc_core9sc_signalIiLNS_16<b>sc_writer_policyE0</b>EEE</font></div></div><div><br></div><div>So in RTTI we have <font face="arial, helvetica, sans-serif">mangled sc_core::sc_signal<int, (sc_core::sc_writer_policy)0></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Is it possible to make Clang emitting same type-name in both cases? </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Originally I've discovered this issue with Clang++5.0. Just tried with Clang++6.0 and it is still there.</font></div><div><font face="arial, helvetica, sans-serif">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)</font></div><div><font face="arial, helvetica, sans-serif"> </font></div><div><font face="arial, helvetica, sans-serif">Thanks,</font></div><div><font face="arial, helvetica, sans-serif">Roman</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><br></div></div>
</blockquote></div><br></div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>
</blockquote></div><br></div>
</blockquote></div></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div></div>