[lldb-dev] RTTI does not work stable in LLDB.

Mon Feb 6 14:25:45 PST 2017

Doesn't the DWARF have a record for the VTable itself?  I know PDB does,
you can look up the class name through the VTable debug info record rather
than trying to demangle the name.

On Mon, Feb 6, 2017 at 2:21 PM Greg Clayton via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> Yeah, when doing dynamic type resolution, we look at the first pointer
> inside the pointer and see if it resolves to a virtual table symbol. If it
> does, we extract the class name from the demangled symbol name and try to
> look up. GDB does the same thing. All debuggers do AFAIK.
>
> If the DWARF specified the vtable address in the DWARF on the class
> definition this would help, but without that the only thing we can really
> do is to try and figure out the class and look it up by name. Also, even if
> this is added to future DWARF, it doesn’t fix the problem that we have many
> compilers that don’t have the info so we would still need to do what we do.
>
> If anyone has any better ideas I am all ears?
>
> Greg
>
> On Feb 6, 2017, at 11:48 AM, Robinson, Paul <paul.robinson at sony.com>
> wrote:
>
> So is LLDB expecting the name in the DWARF info to match the demangled
> name of the vtable pointer?  The DWARF spec does not really specify what
> the name of a template instantiation should be, and in particular does not
> *want* to specify whether it matches any given demangler's opinion of the
> name.
> --paulr
>
> *From:* lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org
> <lldb-dev-bounces at lists.llvm.org>] *On Behalf Of *Greg Clayton via
> lldb-dev
> *Sent:* Monday, February 06, 2017 11:08 AM
> *To:* Greg Clayton
> *Cc:* lldb-dev at lists.llvm.org
> *Subject:* Re: [lldb-dev] RTTI does not work stable in LLDB.
>
> So I found the problem. This is a compiler bug. The DWARF for this type
> looks like:
>
>
> 0x000065da:     TAG_structure_type [112] *
>                  AT_containing_type( {0x0000000000006628} )
>                  AT_name( "derived0<int, int, 1024>" )
>                  AT_byte_size( 0x08 )
>                  AT_decl_file( "/private/tmp/main.cpp" )
>                  AT_decl_line( 9 )
>
> But all of the type info in the symbol table has has the type named as
> "derived0<int, int, 1024u>”. Note the extra “u” that follows 1024. This
> stops LLDB from being able to lookup the type correctly so we can show the
> dynamic type. In LLDB we check the first pointer inside of a class to see
> if it is a symbol whose name is “vtable for TYPENAME”. If it is, we
> lookup the type “TYPENAME” to find it. In this case we try to lookup "derived0<int,
> int, 1024u>” and we fail since the DWARF has it as "derived0<int, int,
> 1024>”.
>
> I have filed a radar on the compiler here at Apple for the fix.
>
> Greg
>
>
>
> On Feb 6, 2017, at 10:22 AM, Greg Clayton via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
> I am looking at this now. I will let you know what I find.
>
> Greg
>
>
> On Feb 6, 2017, at 10:00 AM, Roman Popov <ripopov at gmail.com> wrote:
>
> Yes, that was my thought.
>
> FYI, checked in GDB: it's working correctly on this testcase showing
> correct dynamic type in both cases.
>
> 2017-02-06 9:48 GMT-08:00 Greg Clayton <gclayton at apple.com>:
> You have found a bug. It should be reporting this correctly but it isn’t.
> I verified it fails on MacOSX.
>
> Greg Clayton
>
>
> On Feb 5, 2017, at 1:19 PM, Roman Popov via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
> Hello,
> I'm observing very strange LLDB behavior: it does not always shows a
> correct dynamic type when I ask for.
>
> Originally I was working with LLDB 3.9, but it looks like trunk version
> behaves the same strange way.
>
> I was able to capture this behavior in a small code snippet:
>
> #include <iostream>
> #include <typeinfo>
>
> using namespace std;
>
> struct base_type {  virtual ~base_type(){} };
>
> template <class T1, class T2, unsigned SIZE>
> struct derived0 : base_type {};
>
> template <class T1, class T2>
> struct derived1 : base_type {};
>
> int main(int argc, char ** argv) {
>
>     base_type * bptr0 = new derived0<int, int, 1024>();
>     base_type * bptr1 = new derived1<int, int >();
>
>     cout << typeid(*bptr0).name() << endl;
>     cout << typeid(*bptr1).name() << endl;
>
>     return 0;
> }
>
>
> lldb --version
> lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision
> 293398)
>   clang revision 293398
>   llvm revision 293398
>
>
> Testing in LLDB:
> (lldb) break set --file main.cpp --line 22
>
> (lldb) expression -d no-run --  bptr1
> (derived1<int, int> *) $2 = 0x0000000000614c40
>
> (lldb) expression -d no-run --  bptr0
> *(base_type *) $3 = 0x0000000000614c20*
>
>
> Can someone explain me why for bptr0 I dont get a  derived0<int, int,
> 1024> * as I expected?
>
>
> Thanks,
> Roman
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170206/28f7b8c0/attachment-0001.html>