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@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 <ripo...@gmail.com 
>> <mailto:ripo...@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 <gclay...@apple.com 
>> <mailto:gclay...@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@lists.llvm.org <mailto:lldb-dev@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 
>>> <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@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>> 
>> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to