date:20170206

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

2017-02-06 Thread Greg Clayton via lldb-dev

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 
>  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 
> #include 
> 
> using namespace std;
> 
> struct base_type {  virtual ~base_type(){} };
> 
> template 
> struct derived0 : base_type {};
> 
> template 
> struct derived1 : base_type {};
> 
> int main(int argc, char ** argv) {
> 
> base_type * bptr0 = new derived0();
> base_type * bptr1 = new derived1();
> 
> 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 *) $2 = 0x00614c40
> 
> (lldb) expression -d no-run --  bptr0
> (base_type *) $3 = 0x00614c20
> 
> 
> Can someone explain me why for bptr0 I dont get a  derived0 * 
> as I expected?
> 
> 
> Thanks,
> Roman
> ___
> 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

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

2017-02-06 Thread Roman Popov via lldb-dev

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 :

> 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> 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 
> #include 
>
> using namespace std;
>
> struct base_type {  virtual ~base_type(){} };
>
> template 
> struct derived0 : base_type {};
>
> template 
> struct derived1 : base_type {};
>
> int main(int argc, char ** argv) {
>
> base_type * bptr0 = new derived0();
> base_type * bptr1 = new derived1();
>
> 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 *) $2 = 0x00614c40
>
> (lldb) expression -d no-run --  bptr0
> *(base_type *) $3 = 0x00614c20*
>
>
> Can someone explain me why for bptr0 I dont get a  derived0 1024> * as I expected?
>
>
> Thanks,
> Roman
> ___
> 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

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

2017-02-06 Thread Greg Clayton via lldb-dev

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  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  >:
> 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 
>> 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 
>> #include 
>> 
>> using namespace std;
>> 
>> struct base_type {  virtual ~base_type(){} };
>> 
>> template 
>> struct derived0 : base_type {};
>> 
>> template 
>> struct derived1 : base_type {};
>> 
>> int main(int argc, char ** argv) {
>> 
>> base_type * bptr0 = new derived0();
>> base_type * bptr1 = new derived1();
>> 
>> 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 *) $2 = 0x00614c40
>> 
>> (lldb) expression -d no-run --  bptr0
>> (base_type *) $3 = 0x00614c20
>> 
>> 
>> Can someone explain me why for bptr0 I dont get a  derived0 
>> * as I expected?
>> 
>> 
>> Thanks,
>> Roman
>> ___
>> 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

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

2017-02-06 Thread Greg Clayton via lldb-dev

So I found the problem. This is a compiler bug. The DWARF for this type looks 
like:

0x65da: TAG_structure_type [112] *
 AT_containing_type( {0x6628} )
 AT_name( "derived0" )
 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”. 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” and we fail since the DWARF has it as "derived0”.

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 
>  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 > > 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 > >:
>> 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 
>>> 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 
>>> #include 
>>> 
>>> using namespace std;
>>> 
>>> struct base_type {  virtual ~base_type(){} };
>>> 
>>> template 
>>> struct derived0 : base_type {};
>>> 
>>> template 
>>> struct derived1 : base_type {};
>>> 
>>> int main(int argc, char ** argv) {
>>> 
>>> base_type * bptr0 = new derived0();
>>> base_type * bptr1 = new derived1();
>>> 
>>> 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 *) $2 = 0x00614c40
>>> 
>>> (lldb) expression -d no-run --  bptr0
>>> (base_type *) $3 = 0x00614c20
>>> 
>>> 
>>> Can someone explain me why for bptr0 I dont get a  derived0 
>>> * as I expected?
>>> 
>>> 
>>> Thanks,
>>> Roman
>>> ___
>>> 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

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

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

2017-02-06 Thread Robinson, Paul via lldb-dev

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-boun...@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@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:

0x65da: TAG_structure_type [112] *
 AT_containing_type( {0x6628} )
 AT_name( "derived0" )
 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”. 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” and we fail since the DWARF has it as "derived0”.

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 
mailto: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 
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 
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 
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 
#include 

using namespace std;

struct base_type {  virtual ~base_type(){} };

template 
struct derived0 : base_type {};

template 
struct derived1 : base_type {};

int main(int argc, char ** argv) {

base_type * bptr0 = new derived0();
base_type * bptr1 = new derived1();

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 *) $2 = 0x00614c40

(lldb) expression -d no-run --  bptr0
(base_type *) $3 = 0x00614c20

Can someone explain me why for bptr0 I dont get a  derived0 * 
as I expected?

Thanks,
Roman
___
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

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

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

2017-02-06 Thread Roman Popov via lldb-dev

I confirm GCC4.8 puts derived0 into DWARF and LLDB
correctly identifies dynamic type.


2017-02-06 11:48 GMT-08:00 Robinson, Paul via lldb-dev <
lldb-dev@lists.llvm.org>:

> 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-boun...@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@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:
>
>
>
> 0x65da: TAG_structure_type [112] *
>  AT_containing_type( {0x6628} )
>  AT_name( "derived0" )
>  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”. 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, 1024u>” and we fail since the DWARF has it as "derived0 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  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 :
>
> 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> 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 
>
> #include 
>
>
>
> using namespace std;
>
>
>
> struct base_type {  virtual ~base_type(){} };
>
>
>
> template 
>
> struct derived0 : base_type {};
>
>
>
> template 
>
> struct derived1 : base_type {};
>
>
>
> int main(int argc, char ** argv) {
>
>
>
> base_type * bptr0 = new derived0();
>
> base_type * bptr1 = new derived1();
>
>
>
> 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 *) $2 = 0x00614c40
>
>
>
> (lldb) expression -d no-run --  bptr0
>
> *(base_type *) $3 = 0x00614c20*
>
>
>
>
>
> Can someone explain me why for bptr0 I dont get a  derived0 1024> * as I expected?
>
>
>
>
>
> Thanks,
>
> Roman
>
> ___
> 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
>
>
>
> ___
> 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

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

2017-02-06 Thread Greg Clayton via lldb-dev

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  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-boun...@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@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:
>  
> 0x65da: TAG_structure_type [112] *
>  AT_containing_type( {0x6628} )
>  AT_name( "derived0" )
>  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”. 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 1024u>” and we fail since the DWARF has it as "derived0”.
>  
> 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 
> mailto: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  > 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  >:
> 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  > 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 
> #include 
>  
> using namespace std;
>  
> struct base_type {  virtual ~base_type(){} };
>  
> template 
> struct derived0 : base_type {};
>  
> template 
> struct derived1 : base_type {};
>  
> int main(int argc, char ** argv) {
>  
> base_type * bptr0 = new derived0();
> base_type * bptr1 = new derived1();
>  
> 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 *) $2 = 0x00614c40
>  
> (lldb) expression -d no-run --  bptr0
> (base_type *) $3 = 0x00614c20
>  
>  
> Can someone explain me why for bptr0 I dont get a  derived0 * 
> as I expected?
>  
>  
> Thanks,
> Roman
> ___
> 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 
> 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/m

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

2017-02-06 Thread Zachary Turner via lldb-dev

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@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 
> 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-boun...@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@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:
>
>
> 0x65da: TAG_structure_type [112] *
>  AT_containing_type( {0x6628} )
>  AT_name( "derived0" )
>  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”. 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, 1024u>” and we fail since the DWARF has it as "derived0 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  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 :
> 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> 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 
> #include 
>
> using namespace std;
>
> struct base_type {  virtual ~base_type(){} };
>
> template 
> struct derived0 : base_type {};
>
> template 
> struct derived1 : base_type {};
>
> int main(int argc, char ** argv) {
>
> base_type * bptr0 = new derived0();
> base_type * bptr1 = new derived1();
>
> 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 *) $2 = 0x00614c40
>
> (lldb) expression -d no-run --  bptr0
> *(base_type *) $3 = 0x00614c20*
>
>
> Can someone explain me why for bptr0 I dont get a  derived0 1024> * as I expected?
>
>
> Thanks,
> Roman
> ___
> 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
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>

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

2017-02-06 Thread Greg Clayton via lldb-dev

It just says where it is inside the class itself, not what the value of the 
vtable pointer is:

0x6628: TAG_structure_type [112] *
 AT_containing_type( {0x6628} )
 AT_name( "base_type" )
 AT_byte_size( 0x08 )
 AT_decl_file( "/private/tmp/main.cpp" )
 AT_decl_line( 6 )

0x6634: TAG_member [4]  
 AT_name( "_vptr$base_type" )
 AT_type( {0x4a41} ( __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  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 
> mailto:lldb-dev@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 > > 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-boun...@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@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:
>>  
>> 0x65da: TAG_structure_type [112] *
>>  AT_containing_type( {0x6628} )
>>  AT_name( "derived0" )
>>  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”. 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, 1024u>” and we fail since the DWARF has it as "derived0> 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 
>> mailto: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 > > 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 > >:
>> 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 
>> 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 
>> #include 
>>  
>> using namespace std;
>>  
>> struct base_type {  virtual ~base_type(){} };
>>  
>> template 
>> struct derived0 : base_type {};
>>  
>> template 
>> struct derived1 : base_type {};
>>  
>> int main(int argc, char ** argv) {
>>  
>> base_type *

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

2017-02-06 Thread Robinson, Paul via lldb-dev

It's not practical for the DWARF to try to identify the actual address of the 
vtable; that address might not be available.
it seems like we could hang onto the linkage_name of the vtable though, 
somewhere, so you wouldn't be relying on the demangler you have available at 
runtime to produce the same string that the compiler did at compile time.  The 
symbolic name of the vtable should be unambiguous (one hopes!) but not depend 
on the existence of the vtable in any particular place.
Doesn't solve the problem for today's compilers, granted.
--paulr

P.S. It would be helpful to have these things come up *before* the next rev of 
the spec is frozen.  Just sayin'.  ☺

From: Greg Clayton [mailto:gclay...@apple.com]
Sent: Monday, February 06, 2017 2:35 PM
To: Zachary Turner
Cc: Robinson, Paul; LLDB Dev (lldb-dev@lists.llvm.org)
Subject: Re: [lldb-dev] RTTI does not work stable in LLDB.

It just says where it is inside the class itself, not what the value of the 
vtable pointer is:

0x6628: TAG_structure_type [112] *
 AT_containing_type( {0x6628} )
 AT_name( "base_type" )
 AT_byte_size( 0x08 )
 AT_decl_file( "/private/tmp/main.cpp" )
 AT_decl_line( 6 )

0x6634: TAG_member [4]
 AT_name( "_vptr$base_type" )
 AT_type( {0x4a41} ( __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 
mailto:ztur...@google.com>> 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 
mailto:lldb-dev@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 
mailto:paul.robin...@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-boun...@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@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:

0x65da: TAG_structure_type [112] *
 AT_containing_type( {0x6628} )
 AT_name( "derived0" )
 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”. 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” and we fail since the DWARF has it as "derived0”.

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 
mailto: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 
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 
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 
mailto:lldb-dev@lists.llvm.org>> wrote:

Hel

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

2017-02-06 Thread Greg Clayton via lldb-dev


> On Feb 6, 2017, at 3:38 PM, Robinson, Paul  wrote:
> 
> It's not practical for the DWARF to try to identify the actual address of the 
> vtable; that address might not be available.
> it seems like we could hang onto the linkage_name of the vtable though, 
> somewhere, so you wouldn't be relying on the demangler you have available at 
> runtime to produce the same string that the compiler did at compile time.  
> The symbolic name of the vtable should be unambiguous (one hopes!) but not 
> depend on the existence of the vtable in any particular place.
> Doesn't solve the problem for today's compilers, granted.
> --paulr
>  
> P.S. It would be helpful to have these things come up *before* the next rev 
> of the spec is frozen.  Just sayin'.  J
>   <>
We had just identified this today and realized it was a problem so we had no 
idea there was a problem until today. Debuggers have been doing this pretty 
reliably for the past 15 years, so it was never anything we actually needed 
extra support for since it was so easy to do. 

Greg



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

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

2017-02-06 Thread Robinson, Paul via lldb-dev

Yes, I do get that it was just unfortunate timing.  Sorry for failing at being 
light-hearted.

I suspect the compiler can be persuaded to emit a name consistent with the 
demangling of the vtable name.  Despite being the way-things-have-worked for a 
long time, it still seems moderately fragile, especially in the face of various 
compiler-list debates about what the name actually should contain.
--paulr

From: Greg Clayton [mailto:gclay...@apple.com]
Sent: Monday, February 06, 2017 4:38 PM
To: Robinson, Paul
Cc: Zachary Turner; LLDB Dev (lldb-dev@lists.llvm.org)
Subject: Re: [lldb-dev] RTTI does not work stable in LLDB.


On Feb 6, 2017, at 3:38 PM, Robinson, Paul 
mailto:paul.robin...@sony.com>> wrote:

It's not practical for the DWARF to try to identify the actual address of the 
vtable; that address might not be available.
it seems like we could hang onto the linkage_name of the vtable though, 
somewhere, so you wouldn't be relying on the demangler you have available at 
runtime to produce the same string that the compiler did at compile time.  The 
symbolic name of the vtable should be unambiguous (one hopes!) but not depend 
on the existence of the vtable in any particular place.
Doesn't solve the problem for today's compilers, granted.
--paulr

P.S. It would be helpful to have these things come up *before* the next rev of 
the spec is frozen.  Just sayin'.  :)


We had just identified this today and realized it was a problem so we had no 
idea there was a problem until today. Debuggers have been doing this pretty 
reliably for the past 15 years, so it was never anything we actually needed 
extra support for since it was so easy to do.

Greg



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

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

2017-02-06 Thread Roman Popov via lldb-dev

Hello,
I just found out that sometimes I don't get correct dynamic type in LLDB
even if I compile with g++.  How can I get typeinfo/vtable dump from LLDB
to check if it is still the same name matching issue?

2017-02-06 17:04 GMT-08:00 Robinson, Paul via lldb-dev <
lldb-dev@lists.llvm.org>:

> Yes, I do get that it was just unfortunate timing.  Sorry for failing at
> being light-hearted.
>
>
>
> I suspect the compiler can be persuaded to emit a name consistent with the
> demangling of the vtable name.  Despite being the way-things-have-worked
> for a long time, it still seems moderately fragile, especially in the face
> of various compiler-list debates about what the name actually should
> contain.
>
> --paulr
>
>
>
> *From:* Greg Clayton [mailto:gclay...@apple.com]
> *Sent:* Monday, February 06, 2017 4:38 PM
> *To:* Robinson, Paul
> *Cc:* Zachary Turner; LLDB Dev (lldb-dev@lists.llvm.org)
> *Subject:* Re: [lldb-dev] RTTI does not work stable in LLDB.
>
>
>
>
>
> On Feb 6, 2017, at 3:38 PM, Robinson, Paul  wrote:
>
>
>
> It's not practical for the DWARF to try to identify the actual address of
> the vtable; that address might not be available.
>
> it seems like we could hang onto the linkage_name of the vtable though,
> somewhere, so you wouldn't be relying on the demangler you have available
> at runtime to produce the same string that the compiler did at compile
> time.  The symbolic name of the vtable should be unambiguous (one hopes!)
> but not depend on the existence of the vtable in any particular place.
>
> Doesn't solve the problem for today's compilers, granted.
>
> --paulr
>
>
>
> P.S. It would be helpful to have these things come up *before* the next
> rev of the spec is frozen.  Just sayin'.  J
>
>
>
>
>
> We had just identified this today and realized it was a problem so we had
> no idea there was a problem until today. Debuggers have been doing this
> pretty reliably for the past 15 years, so it was never anything we actually
> needed extra support for since it was so easy to do.
>
>
>
> Greg
>
>
>
>
>
>
>
> ___
> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

13 matches

Site Navigation

Mail list logo

Footer information