It just says where it is inside the class itself, not what the value of the
vtable pointer is:
0x00006628: TAG_structure_type [112] *
AT_containing_type( {0x0000000000006628} )
AT_name( "base_type" )
AT_byte_size( 0x08 )
AT_decl_file( "/private/tmp/main.cpp" )
AT_decl_line( 6 )
0x00006634: TAG_member [4]
AT_name( "_vptr$base_type" )
AT_type( {0x0000000000004a41} ( __vtbl_ptr_type* ) )
AT_data_member_location( 0x00 )
AT_artificial( true )
Just says “the vtable is at offset zero inside the class”. Not helpful for
reading any vtable pointer and trying to figure out which class it belongs to.
Greg
> On Feb 6, 2017, at 2:25 PM, Zachary Turner <[email protected]> wrote:
>
> 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
> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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:[email protected]
>> <mailto:[email protected]>] On Behalf Of Greg Clayton via
>> lldb-dev
>> Sent: Monday, February 06, 2017 11:08 AM
>> To: Greg Clayton
>> Cc: [email protected] <mailto:[email protected]>
>> 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
>> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>>:
>> 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
>> <[email protected] <mailto:[email protected]>> 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
>> <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
>> [email protected] <mailto:[email protected]>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
> _______________________________________________
> lldb-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
