Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type

[Jim Ingham via lldb-dev]

> On Feb 28, 2018, at 1:09 PM, jonas echterhoff  wrote:
> 
> 
> 
>> On Feb 28, 2018, at 9:27 PM, Jim Ingham  wrote:
>> 
>> Interesting.  
>> 
>> First off, you can turn off fetching dynamic values globally (including in 
>> the Xcode Locals view) by putting:
>> 
>> settings set target.prefer-dynamic-value no-dynamic-values
> 
>> in your ~/.lldbinit file.  You can toggle this on and off in a session, 
>> though Xcode won't notice you've changed the value till you cause it to 
>> refresh the locals (step or whatever).
> 
> This will fix the output of "frame variable". But it does not seem to fix the 
> variable display in the UI.

They must be setting the dynamic value directly when they fetch the values.  
That of course overrides the general setting.  I'll go see why they do that, 
but that won't help you for now.

> 
>> We do log the process of finding the dynamic type.  You can see this by 
>> running the command:
>> 
>> log enable -f /tmp/lldb-object-log.txt lldb object
>> 
>> Probably easiest to put that in your .lldbinit.
>> 
>> That channel also logs when we read in modules, and so it might be a little 
>> chatty, but you should see:
>> 
>> : static-type = '' has vtable symbol 'vtable for 
>> '
>> 
>> and then some more messages that trace our attempt to look up DYNAMIC CLASS. 
>>  If you turn on those logs, what do you see for these classes?
> 
> 0x00010f62ecd0: static-type = 'Transform *' has vtable symbol 'vtable for 
> Transform'
> 
> 0x00010f62ecd0: static-type = 'Transform *' has dynamic type: 
> uid={0x100012d7a}, type-name='Transform'

Grr...  We go from the name in the vtable symbol to the class type using 
Module::FindTypes, passing the exact_match flag 'cause we know this is an exact 
match.  Turns out the Module::FindTypes only obeys its exact_match flag if 
either the name you pass in starts with :: or if you can dial up the exact type 
kind (struct, class, enum, etc...) you are looking for.  We can't do the latter 
here because we don't know whether the dynamic type is a class or a struct, and 
we were just passing the name we got from the vtable.

I have a small fix for the dynamic type issue in r326412.  Fixing the FindTypes 
behavior is more involved, and I don't know whether other places rely on this 
misbehavior. I filed:

https://bugs.llvm.org/show_bug.cgi?id=36556

to examine that issue further.

Thanks for reporting this.

Jim


> 
> jonas
> 
>> 
>> Jim
>> 
>> 
>>> On Feb 28, 2018, at 12:03 PM, jonas echterhoff  wrote:
>>> 
>>> 
>>> 
 On Feb 28, 2018, at 7:14 PM, Jim Ingham  wrote:
 
 Jonas,
 
 What are you using to inspect the this pointer?
>>> 
>>> Normally, the Xcode debugger UI.
>>> 
 You can use "frame variable" (the equivalent of gdb's "info locals") which 
 just relies on debug info or the expression evaluator e.g. "print".  Do 
 both methods show the same problem?
>>> 
>>> (lldb) frame variable this
>>> (Scripting::UnityEngine::Transform *) this = 0x00010fe2eb20
>>> 
>>> That gives me the wrong namespace
>>> 
>>> (lldb) print this
>>> (Scripting::UnityEngine::Transform *) $4 = 0x00010fe2eb20
>>> 
>>> That also gives me the wrong namespace
>>> 
>>> But:
>>> 
>>> (lldb) print *this
>>> (Transform) $5 = {
>>> [...]
>>> 
>>> gives me the correct (global) namespace.
>>> 
>>> Also:
>>> 
>>> (lldb) frame variable -d no-dynamic-values this
>>> (Transform *) this = 0x00010fe2eb20
>>> 
>>> gives me the correct namespace.
>>> 
 
 Also note that lldb by default will try to discern the full dynamic type 
 of the variables it prints.  You can disable this by doing:
 
 (lldb) expr -d no-dynamic-values -- this
 
 or equivalently:
 
 (lldb) frame variable -d no-dynamic-values this
 
 Is it the dynamic value resolution that's causing the incorrect printing?
>>> 
>>> Yes, both of those above give me the correct types!
>>> 
>>> Now, this is already very helpful - Thank you! 
>>> This means I can get correct values using the lldb console. If there was 
>>> some way to make the Xcode UI show the correct values, that would be even 
>>> better.
>>> 
>>> jonas
>>> 
 
 Jim
 
 
 
 
> On Feb 28, 2018, at 3:03 AM, jonas echterhoff via lldb-dev 
>  wrote:
> 
> 
>> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov  wrote:
>> 
>> On 02/28/2018 11:31 AM, jonas echterhoff via lldb-dev wrote:
>> 
>>> I'm using lldb-900.0.64.
>>   ^^
>>   ??
>> Latest official release is 5.0.1; also there are 6.0.0 (at -rc3, the 
>> next release)
>> and 7.0.0 (a.k.a SVN trunk). What's the 'version' output of your LLDB 
>> prompt?
> 
> It is what I posted:
> 
> jechter$ lldb --version
> lldb-900.0.64
> Swift-4.0
> 
> Maybe Apple uses a different versioning scheme for 

[lldb-dev] [Bug 36556] New: Module::FindTypes ignores the exact flag in some circumstances

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=36556

Bug ID: 36556
   Summary: Module::FindTypes ignores the exact flag in some
circumstances
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: jing...@apple.com
CC: llvm-b...@lists.llvm.org

By code inspection, Module::FindTypes ignores the exact flag if the type class
is Any and the name you pass in doesn't start with a ::.  I don't know how
widely this is used - it broke finding dynamic types for C++ if you have two
classes with the same base name.  I have a local fix for that which didn't
involve changing the behavior of FindTypes.  I also don't know whether there
are other uses that rely on this misbehavior.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type

[jonas echterhoff via lldb-dev]

> On Feb 28, 2018, at 9:27 PM, Jim Ingham  wrote:
> 
> Interesting.  
> 
> First off, you can turn off fetching dynamic values globally (including in 
> the Xcode Locals view) by putting:
> 
> settings set target.prefer-dynamic-value no-dynamic-values

> in your ~/.lldbinit file.  You can toggle this on and off in a session, 
> though Xcode won't notice you've changed the value till you cause it to 
> refresh the locals (step or whatever).

This will fix the output of "frame variable". But it does not seem to fix the 
variable display in the UI.

> We do log the process of finding the dynamic type.  You can see this by 
> running the command:
> 
> log enable -f /tmp/lldb-object-log.txt lldb object
> 
> Probably easiest to put that in your .lldbinit.
> 
> That channel also logs when we read in modules, and so it might be a little 
> chatty, but you should see:
> 
> : static-type = '' has vtable symbol 'vtable for 
> '
> 
> and then some more messages that trace our attempt to look up DYNAMIC CLASS.  
> If you turn on those logs, what do you see for these classes?

0x00010f62ecd0: static-type = 'Transform *' has vtable symbol 'vtable for 
Transform'

0x00010f62ecd0: static-type = 'Transform *' has dynamic type: 
uid={0x100012d7a}, type-name='Transform'

jonas

> 
> Jim
> 
> 
>> On Feb 28, 2018, at 12:03 PM, jonas echterhoff  wrote:
>> 
>> 
>> 
>>> On Feb 28, 2018, at 7:14 PM, Jim Ingham  wrote:
>>> 
>>> Jonas,
>>> 
>>> What are you using to inspect the this pointer?
>> 
>> Normally, the Xcode debugger UI.
>> 
>>> You can use "frame variable" (the equivalent of gdb's "info locals") which 
>>> just relies on debug info or the expression evaluator e.g. "print".  Do 
>>> both methods show the same problem?
>> 
>> (lldb) frame variable this
>> (Scripting::UnityEngine::Transform *) this = 0x00010fe2eb20
>> 
>> That gives me the wrong namespace
>> 
>> (lldb) print this
>> (Scripting::UnityEngine::Transform *) $4 = 0x00010fe2eb20
>> 
>> That also gives me the wrong namespace
>> 
>> But:
>> 
>> (lldb) print *this
>> (Transform) $5 = {
>> [...]
>> 
>> gives me the correct (global) namespace.
>> 
>> Also:
>> 
>> (lldb) frame variable -d no-dynamic-values this
>> (Transform *) this = 0x00010fe2eb20
>> 
>> gives me the correct namespace.
>> 
>>> 
>>> Also note that lldb by default will try to discern the full dynamic type of 
>>> the variables it prints.  You can disable this by doing:
>>> 
>>> (lldb) expr -d no-dynamic-values -- this
>>> 
>>> or equivalently:
>>> 
>>> (lldb) frame variable -d no-dynamic-values this
>>> 
>>> Is it the dynamic value resolution that's causing the incorrect printing?
>> 
>> Yes, both of those above give me the correct types!
>> 
>> Now, this is already very helpful - Thank you! 
>> This means I can get correct values using the lldb console. If there was 
>> some way to make the Xcode UI show the correct values, that would be even 
>> better.
>> 
>> jonas
>> 
>>> 
>>> Jim
>>> 
>>> 
>>> 
>>> 
 On Feb 28, 2018, at 3:03 AM, jonas echterhoff via lldb-dev 
  wrote:
 
 
> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov  wrote:
> 
> On 02/28/2018 11:31 AM, jonas echterhoff via lldb-dev wrote:
> 
>> I'm using lldb-900.0.64.
>^^
>??
> Latest official release is 5.0.1; also there are 6.0.0 (at -rc3, the next 
> release)
> and 7.0.0 (a.k.a SVN trunk). What's the 'version' output of your LLDB 
> prompt?
 
 It is what I posted:
 
 jechter$ lldb --version
 lldb-900.0.64
 Swift-4.0
 
 Maybe Apple uses a different versioning scheme for lldb distributed with 
 their toolchains?
> 
>> Unfortunately, I have not yet succeeded in coming up with a small, 
>> independent repro case which shows this problem.
> 
> IIUC this is it:
 
 [...]
 
> Here 'this' is different between calls to obj2.f () and obj2.g () 
> (0x7fffdb50 vs.
> 0x7fffdb40), and objects are shown as different as well - {111, 
> 222} vs. {333, 444}.
 
 Thanks. What you are showing there seems very peculiar. 
 
 But I don't think it's the same problem as I have (and also, using the 
 same steps on my machine does not repro the problem you showed - I get the 
 same value for "this" and it's members between the calls to S::B::f and 
 S::B::g).
 
 My problem was not about showing a wrong object (My "this" pointer value 
 was correct), but about showing a wrong type representation of the correct 
 object data.
 
 jonas
 
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> 
>> 
> 

___
lldb-dev mailing list

Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type

[Jim Ingham via lldb-dev]

Interesting.  

First off, you can turn off fetching dynamic values globally (including in the 
Xcode Locals view) by putting:

settings set target.prefer-dynamic-value no-dynamic-values

in your ~/.lldbinit file.  You can toggle this on and off in a session, though 
Xcode won't notice you've changed the value till you cause it to refresh the 
locals (step or whatever).

We do log the process of finding the dynamic type.  You can see this by running 
the command:

log enable -f /tmp/lldb-object-log.txt lldb object

Probably easiest to put that in your .lldbinit.

That channel also logs when we read in modules, and so it might be a little 
chatty, but you should see:

: static-type = '' has vtable symbol 'vtable for 
'

and then some more messages that trace our attempt to look up DYNAMIC CLASS.  
If you turn on those logs, what do you see for these classes?

Jim


> On Feb 28, 2018, at 12:03 PM, jonas echterhoff  wrote:
> 
> 
> 
>> On Feb 28, 2018, at 7:14 PM, Jim Ingham  wrote:
>> 
>> Jonas,
>> 
>> What are you using to inspect the this pointer?
> 
> Normally, the Xcode debugger UI.
> 
>> You can use "frame variable" (the equivalent of gdb's "info locals") which 
>> just relies on debug info or the expression evaluator e.g. "print".  Do both 
>> methods show the same problem?
> 
> (lldb) frame variable this
> (Scripting::UnityEngine::Transform *) this = 0x00010fe2eb20
> 
> That gives me the wrong namespace
> 
> (lldb) print this
> (Scripting::UnityEngine::Transform *) $4 = 0x00010fe2eb20
> 
> That also gives me the wrong namespace
> 
> But:
> 
> (lldb) print *this
> (Transform) $5 = {
> [...]
> 
> gives me the correct (global) namespace.
> 
> Also:
> 
> (lldb) frame variable -d no-dynamic-values this
> (Transform *) this = 0x00010fe2eb20
> 
> gives me the correct namespace.
> 
>> 
>> Also note that lldb by default will try to discern the full dynamic type of 
>> the variables it prints.  You can disable this by doing:
>> 
>> (lldb) expr -d no-dynamic-values -- this
>> 
>> or equivalently:
>> 
>> (lldb) frame variable -d no-dynamic-values this
>> 
>> Is it the dynamic value resolution that's causing the incorrect printing?
> 
> Yes, both of those above give me the correct types!
> 
> Now, this is already very helpful - Thank you! 
> This means I can get correct values using the lldb console. If there was some 
> way to make the Xcode UI show the correct values, that would be even better.
> 
> jonas
> 
>> 
>> Jim
>> 
>> 
>> 
>> 
>>> On Feb 28, 2018, at 3:03 AM, jonas echterhoff via lldb-dev 
>>>  wrote:
>>> 
>>> 
 On Feb 28, 2018, at 11:19 AM, Dmitry Antipov  wrote:
 
 On 02/28/2018 11:31 AM, jonas echterhoff via lldb-dev wrote:
 
> I'm using lldb-900.0.64.
 ^^
 ??
 Latest official release is 5.0.1; also there are 6.0.0 (at -rc3, the next 
 release)
 and 7.0.0 (a.k.a SVN trunk). What's the 'version' output of your LLDB 
 prompt?
>>> 
>>> It is what I posted:
>>> 
>>> jechter$ lldb --version
>>> lldb-900.0.64
>>> Swift-4.0
>>> 
>>> Maybe Apple uses a different versioning scheme for lldb distributed with 
>>> their toolchains?
 
> Unfortunately, I have not yet succeeded in coming up with a small, 
> independent repro case which shows this problem.
 
 IIUC this is it:
>>> 
>>> [...]
>>> 
 Here 'this' is different between calls to obj2.f () and obj2.g () 
 (0x7fffdb50 vs.
 0x7fffdb40), and objects are shown as different as well - {111, 
 222} vs. {333, 444}.
>>> 
>>> Thanks. What you are showing there seems very peculiar. 
>>> 
>>> But I don't think it's the same problem as I have (and also, using the same 
>>> steps on my machine does not repro the problem you showed - I get the same 
>>> value for "this" and it's members between the calls to S::B::f and S::B::g).
>>> 
>>> My problem was not about showing a wrong object (My "this" pointer value 
>>> was correct), but about showing a wrong type representation of the correct 
>>> object data.
>>> 
>>> jonas
>>> 
>>> ___
>>> 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] lldb showing wrong type structure for virtual pointer type

[jonas echterhoff via lldb-dev]

> On Feb 28, 2018, at 7:14 PM, Jim Ingham  wrote:
> 
> Jonas,
> 
> What are you using to inspect the this pointer?

Normally, the Xcode debugger UI.

>  You can use "frame variable" (the equivalent of gdb's "info locals") which 
> just relies on debug info or the expression evaluator e.g. "print".  Do both 
> methods show the same problem?

(lldb) frame variable this
(Scripting::UnityEngine::Transform *) this = 0x00010fe2eb20

That gives me the wrong namespace

(lldb) print this
(Scripting::UnityEngine::Transform *) $4 = 0x00010fe2eb20

That also gives me the wrong namespace

But:

(lldb) print *this
(Transform) $5 = {
[...]

gives me the correct (global) namespace.

Also:

(lldb) frame variable -d no-dynamic-values this
(Transform *) this = 0x00010fe2eb20

gives me the correct namespace.

> 
> Also note that lldb by default will try to discern the full dynamic type of 
> the variables it prints.  You can disable this by doing:
> 
> (lldb) expr -d no-dynamic-values -- this
> 
> or equivalently:
> 
> (lldb) frame variable -d no-dynamic-values this
> 
> Is it the dynamic value resolution that's causing the incorrect printing?

Yes, both of those above give me the correct types!

Now, this is already very helpful - Thank you! 
This means I can get correct values using the lldb console. If there was some 
way to make the Xcode UI show the correct values, that would be even better.

jonas

> 
> Jim
> 
> 
> 
> 
>> On Feb 28, 2018, at 3:03 AM, jonas echterhoff via lldb-dev 
>>  wrote:
>> 
>> 
>>> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov  wrote:
>>> 
>>> On 02/28/2018 11:31 AM, jonas echterhoff via lldb-dev wrote:
>>> 
 I'm using lldb-900.0.64.
>>>  ^^
>>>  ??
>>> Latest official release is 5.0.1; also there are 6.0.0 (at -rc3, the next 
>>> release)
>>> and 7.0.0 (a.k.a SVN trunk). What's the 'version' output of your LLDB 
>>> prompt?
>> 
>> It is what I posted:
>> 
>> jechter$ lldb --version
>> lldb-900.0.64
>> Swift-4.0
>> 
>> Maybe Apple uses a different versioning scheme for lldb distributed with 
>> their toolchains?
>>> 
 Unfortunately, I have not yet succeeded in coming up with a small, 
 independent repro case which shows this problem.
>>> 
>>> IIUC this is it:
>> 
>> [...]
>> 
>>> Here 'this' is different between calls to obj2.f () and obj2.g () 
>>> (0x7fffdb50 vs.
>>> 0x7fffdb40), and objects are shown as different as well - {111, 
>>> 222} vs. {333, 444}.
>> 
>> Thanks. What you are showing there seems very peculiar. 
>> 
>> But I don't think it's the same problem as I have (and also, using the same 
>> steps on my machine does not repro the problem you showed - I get the same 
>> value for "this" and it's members between the calls to S::B::f and S::B::g).
>> 
>> My problem was not about showing a wrong object (My "this" pointer value was 
>> correct), but about showing a wrong type representation of the correct 
>> object data.
>> 
>> jonas
>> 
>> ___
>> 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] Issue: print std unique pointer

[Pavel Labath via lldb-dev]

I think this is the interesting part: std::__uniq_ptr_impl

There is no such type in the example I posted. It looks like the
implementation of std::unique_ptr changed, and they added an extra
member object. This tells me the fix should be in the data formatter
for std::unique_ptr and not std::tuple (which makes sense, because
your std::tuple tests are still passing (?)). We should detect the new
layout and format based on that. It would also be good to know in
which libstdc++ version this changed, so we can leave a note to future
selves about when can this be cleaned up.

On 28 February 2018 at 05:25, Alexandre Yukio Yamashita
 wrote:
> All the test cases in TestDataFormatterStdUniquePtr were failing.
> My std::unique_ptr layout is:
>
> (std::unique_ptr) iup = {
>   (std::__uniq_ptr_impl) _M_t = {
> (std::tuple >) _M_t = {
>   (std::_Tuple_impl<0, int *, std::default_delete >)
> std::_Tuple_impl<0, int *, std::default_delete > = {
> (std::_Head_base<0, int *, false>) std::_Head_base<0, int *,
> false> = {
>   (int *) _M_head_impl = 0x10041c20
> }
>   }
> }
>   }
> }
>
> It is showing "std::tuple >) _M_t"
> instead of "std::_Tuple_impl<0, int *, std::default_delete >".
>
>
> Em 27/02/2018 19:34, Greg Clayton escreveu:
>
> Then the question becomes how can we identify the STL that is being used
> correctly so we can do the right thing. I worry that if std::unique_ptr
> isn't working that many many other STL things won't work as well. We are
> tuned for a specific STL
>
> On Feb 27, 2018, at 2:12 PM, Pavel Labath via lldb-dev
>  wrote:
>
> This probably isn't arch-dependent. More likely you just have a
> different version of libstdc++. Can you share how the std::unique_ptr
> layout looks like for you. This is how my std::unique_ptr looks like
> (from libstdc++.so.6.0.22):
>
> (lldb) fr var X -R -T
> (std::unique_ptr) X = {
>  (std::unique_ptr::__tuple_type) _M_t = {
>(std::_Tuple_impl<0, int *, std::default_delete >)
> std::_Tuple_impl<0, int *, std::default_delete > = {
>  (std::_Head_base<0, int *, false>) std::_Head_base<0, int *, false> = {
>(int *) _M_head_impl = 0x55768c20
>  }
>}
>  }
> }
>
> On 27 February 2018 at 12:26, Alexandre Yukio Yamashita via lldb-dev
>  wrote:
>
> Hi,
>
> LLDB is printing a empty value for unique pointers in PowerPC.
> And I am investigating a solution for this problem.
>
> The problem occurs because the ptr_obj variable has a empty value in
> Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp:73.
>
> I could solve it, changing this line
> Plugins/Language/CPlusPlus/LibStdcppTuple.cpp:68
> from:
> if (name_str.startswith("std::_Tuple_impl<")) {
> to:
> if (name_str.startswith("std::_Tuple_impl<") ||
> name_str.startswith("_M_t") ) {
>
> After this change, the test TestDataFormatterStdUniquePtr pass with success.
> And the unique pointers are displayed correctly.
>
> Is there a better solution for that?
>
> Thanks.
> Alexandre.
>
>
> --
> Alexandre Yukio Yamashita (DSB)
> Instituto de Pesquisas Eldorado
> www.eldorado.org.br
> +55 19 3757 3201 / +55 19 9 8336 5553
> ___
> 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
>
>
> --
> Alexandre Yukio Yamashita (DSB)
> Instituto de Pesquisas Eldorado
> www.eldorado.org.br
> +55 19 3757 3201 / +55 19 9 8336 5553
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type

[Jim Ingham via lldb-dev]

Jonas,

What are you using to inspect the this pointer?  You can use "frame variable" 
(the equivalent of gdb's "info locals") which just relies on debug info or the 
expression evaluator e.g. "print".  Do both methods show the same problem?

Also note that lldb by default will try to discern the full dynamic type of the 
variables it prints.  You can disable this by doing:

(lldb) expr -d no-dynamic-values -- this

or equivalently:

(lldb) frame variable -d no-dynamic-values this

Is it the dynamic value resolution that's causing the incorrect printing?

Jim




> On Feb 28, 2018, at 3:03 AM, jonas echterhoff via lldb-dev 
>  wrote:
> 
> 
>> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov  wrote:
>> 
>> On 02/28/2018 11:31 AM, jonas echterhoff via lldb-dev wrote:
>> 
>>> I'm using lldb-900.0.64.
>>   ^^
>>   ??
>> Latest official release is 5.0.1; also there are 6.0.0 (at -rc3, the next 
>> release)
>> and 7.0.0 (a.k.a SVN trunk). What's the 'version' output of your LLDB prompt?
> 
> It is what I posted:
> 
> jechter$ lldb --version
> lldb-900.0.64
>  Swift-4.0
> 
> Maybe Apple uses a different versioning scheme for lldb distributed with 
> their toolchains?
>> 
>>> Unfortunately, I have not yet succeeded in coming up with a small, 
>>> independent repro case which shows this problem.
>> 
>> IIUC this is it:
> 
> [...]
> 
>> Here 'this' is different between calls to obj2.f () and obj2.g () 
>> (0x7fffdb50 vs.
>> 0x7fffdb40), and objects are shown as different as well - {111, 222} 
>> vs. {333, 444}.
> 
> Thanks. What you are showing there seems very peculiar. 
> 
> But I don't think it's the same problem as I have (and also, using the same 
> steps on my machine does not repro the problem you showed - I get the same 
> value for "this" and it's members between the calls to S::B::f and S::B::g).
> 
> My problem was not about showing a wrong object (My "this" pointer value was 
> correct), but about showing a wrong type representation of the correct object 
> data.
> 
> jonas
> 
> ___
> 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] [Release-testers] [6.0.0 Release] Release Candidate 3 tagged

[Hans Wennborg via lldb-dev]

Thanks! Added to the web page now.

On Tue, Feb 27, 2018 at 9:18 PM, Simon Dardis  wrote:
> Hi,
>
> No major issues seen so far for mips. Binaries uploaded.
>
> SHA256(clang+llvm-6.0.0-rc3-mipsel-linux-gnu.tar.xz)= 
> 6e4fab79cc341a9084dab94cced108daff39fcde14a11e8d7ae454e9f92cb77c
> SHA256(clang+llvm-6.0.0-rc3-mips-linux-gnu.tar.xz)= 
> 54887a039d3d7ccff17a0c7245f4c9d778a1c22f96b619db554849da55293d61
> SHA256(clang+llvm-6.0.0-rc3-x86_64-linux-gnu-debian8.tar.xz)= 
> 75f1a18f23b9d34e3f1ebc223ca0071458b9e8b1392040f9b3d1725566ff6ec1
>
> Thanks,
> Simon
> 
> From: Release-testers [release-testers-boun...@lists.llvm.org] on behalf of 
> Hans Wennborg via Release-testers [release-test...@lists.llvm.org]
> Sent: Friday, February 23, 2018 3:14 PM
> To: Release-testers
> Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev
> Subject: [Release-testers] [6.0.0 Release] Release Candidate 3 tagged
>
> Dear testers,
>
> 6.0.0-rc3 was just tagged, after r325901 on the branch.
>
> There are still a few open blockers, but I'm not sure we'll actually
> end up blocking on all of them. So depending on what comes up, this
> release candidate is probably pretty close to what the final release
> will look like (I'm still hoping for more release notes, though).
>
> I'm hoping we can get to 'final' sometime next week.
>
> Please test, let me know how it goes, and upload binaries.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Issue: print std unique pointer

[Alexandre Yukio Yamashita via lldb-dev]

All the test cases in TestDataFormatterStdUniquePtr were failing.
My std::unique_ptr layout is:

(std::unique_ptr) iup = {
  (std::__uniq_ptr_impl) _M_t = {
(std::tuple >) _M_t = {
  (std::_Tuple_impl<0, int *, std::default_delete >) 
std::_Tuple_impl<0, int *, std::default_delete > = {
(std::_Head_base<0, int *, false>) std::_Head_base<0, int *, false> 
= {
  (int *) _M_head_impl = 0x10041c20
}
  }
}
  }
}

It is showing "std::tuple >) _M_t"
instead of "std::_Tuple_impl<0, int *, std::default_delete >".

Em 27/02/2018 19:34, Greg Clayton escreveu:

Then the question becomes how can we identify the STL that is being used 
correctly so we can do the right thing. I worry that if std::unique_ptr isn't 
working that many many other STL things won't work as well. We are tuned for a 
specific STL



On Feb 27, 2018, at 2:12 PM, Pavel Labath via lldb-dev 
 wrote:

This probably isn't arch-dependent. More likely you just have a
different version of libstdc++. Can you share how the std::unique_ptr
layout looks like for you. This is how my std::unique_ptr looks like
(from libstdc++.so.6.0.22):

(lldb) fr var X -R -T
(std::unique_ptr) X = {
 (std::unique_ptr::__tuple_type) _M_t = {
   (std::_Tuple_impl<0, int *, std::default_delete >)
std::_Tuple_impl<0, int *, std::default_delete > = {
 (std::_Head_base<0, int *, false>) std::_Head_base<0, int *, false> = {
   (int *) _M_head_impl = 0x55768c20
 }
   }
 }
}

On 27 February 2018 at 12:26, Alexandre Yukio Yamashita via lldb-dev
 wrote:


Hi,

LLDB is printing a empty value for unique pointers in PowerPC.
And I am investigating a solution for this problem.

The problem occurs because the ptr_obj variable has a empty value in
Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp:73.

I could solve it, changing this line
Plugins/Language/CPlusPlus/LibStdcppTuple.cpp:68
from:
if (name_str.startswith("std::_Tuple_impl<")) {
to:
if (name_str.startswith("std::_Tuple_impl<") ||
name_str.startswith("_M_t") ) {

After this change, the test TestDataFormatterStdUniquePtr pass with success.
And the unique pointers are displayed correctly.

Is there a better solution for that?

Thanks.
Alexandre.


--
Alexandre Yukio Yamashita (DSB)
Instituto de Pesquisas Eldorado
www.eldorado.org.br
+55 19 3757 3201 / +55 19 9 8336 5553
___
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





--
Alexandre Yukio Yamashita (DSB)
Instituto de Pesquisas Eldorado
www.eldorado.org.br
+55 19 3757 3201 / +55 19 9 8336 5553
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type

[jonas echterhoff via lldb-dev]

> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov  wrote:
> 
> On 02/28/2018 11:31 AM, jonas echterhoff via lldb-dev wrote:
> 
>> I'm using lldb-900.0.64.
>^^
>??
> Latest official release is 5.0.1; also there are 6.0.0 (at -rc3, the next 
> release)
> and 7.0.0 (a.k.a SVN trunk). What's the 'version' output of your LLDB prompt?

It is what I posted:

jechter$ lldb --version
lldb-900.0.64
  Swift-4.0

Maybe Apple uses a different versioning scheme for lldb distributed with their 
toolchains?
> 
>> Unfortunately, I have not yet succeeded in coming up with a small, 
>> independent repro case which shows this problem.
> 
> IIUC this is it:

[...]

> Here 'this' is different between calls to obj2.f () and obj2.g () 
> (0x7fffdb50 vs.
> 0x7fffdb40), and objects are shown as different as well - {111, 222} 
> vs. {333, 444}.

Thanks. What you are showing there seems very peculiar. 

But I don't think it's the same problem as I have (and also, using the same 
steps on my machine does not repro the problem you showed - I get the same 
value for "this" and it's members between the calls to S::B::f and S::B::g).

My problem was not about showing a wrong object (My "this" pointer value was 
correct), but about showing a wrong type representation of the correct object 
data.

jonas

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

[lldb-dev] [Bug 36547] New: Namespace clash displaying 'this'

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=36547

Bug ID: 36547
   Summary: Namespace clash displaying 'this'
   Product: lldb
   Version: 6.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: danti...@nvidia.com
CC: llvm-b...@lists.llvm.org

Created attachment 19970
  --> https://bugs.llvm.org/attachment.cgi?id=19970=edit
Sample program

$ /home/dantipov/.local/llvm-6.0.0/bin/lldb t-class2
(lldb) target create "t-class2"
Current executable set to 't-class2' (x86_64).
(lldb) breakpoint set -n S::B::f
Breakpoint 1: where = t-class2`S::B::f(int) at t-class2.cc:25, address =
0x0040076a
(lldb) breakpoint set -n S::B::g
Breakpoint 2: where = t-class2`S::B::g(int) + 11 at t-class2.cc:26, address =
0x00400789
(lldb) run
Process 5180 launched: '/home/dantipov/tmp/t-class2' (x86_64)
Process 5180 stopped
* thread #1, name = 't-class2', stop reason = breakpoint 1.1
frame #0: 0x0040076a t-class2`S::B::f(this=0x7fffdb50, x=1)
at t-class2.cc:25
   22 struct B: AS {
   23   int id1;
   24   B () { id1 = 444; }
-> 25   virtual int f (int x) { return x + 4; }
   26   int g (int x) { return x + 14; }
   27 };
   28   }
(lldb) bt
* thread #1, name = 't-class2', stop reason = breakpoint 1.1
  * frame #0: 0x0040076a t-class2`S::B::f(this=0x7fffdb50, x=1)
at t-class2.cc:25
frame #1: 0x00400643 t-class2`main(argc=1, argv=0x7fffdc58)
at t-class2.cc:36
frame #2: 0x7712000a
libc.so.6`__libc_start_main(main=(t-class2`main at t-class2.cc:31), argc=1,
argv=0x7fffdc58, init=, fini=,
rtld_fini=, stack_end=0x7fffdc48) at libc-start.c:308
frame #3: 0x0040054a t-class2`_start + 42
(lldb) p this
(S::B *) $0 = 0x7fffdb50
(lldb) p *this
(S::B) $1 = {
  S::AS = (id0 = 111)
  id1 = 222
}
(lldb) c
Process 5180 resuming
Process 5180 stopped
* thread #1, name = 't-class2', stop reason = breakpoint 2.1
frame #0: 0x00400789 t-class2`S::B::g(this=0x7fffdb40, x=1)
at t-class2.cc:26
   23   int id1;
   24   B () { id1 = 444; }
   25   virtual int f (int x) { return x + 4; }
-> 26   int g (int x) { return x + 14; }
   27 };
   28   }
   29   
(lldb) bt
* thread #1, name = 't-class2', stop reason = breakpoint 2.1
  * frame #0: 0x00400789 t-class2`S::B::g(this=0x7fffdb40, x=1)
at t-class2.cc:26
frame #1: 0x00400669 t-class2`main(argc=1, argv=0x7fffdc58)
at t-class2.cc:38
frame #2: 0x7712000a
libc.so.6`__libc_start_main(main=(t-class2`main at t-class2.cc:31), argc=1,
argv=0x7fffdc58, init=, fini=,
rtld_fini=, stack_end=0x7fffdc48) at libc-start.c:308
frame #3: 0x0040054a t-class2`_start + 42
(lldb) p this
(S::B *) $2 = 0x7fffdb40
(lldb) p *this
(S::B) $3 = {
  S::AS = (id0 = 333)
  id1 = 444
}

Here 'this' is different between calls to obj2.f () and obj2.g ()
(0x7fffdb50 vs.
0x7fffdb40), and objects are shown as different as well - {111, 222}
vs. {333, 444}.

OTOH in gdb it is:

$ gdb -q t-class2
Reading symbols from t-class2...done.
(gdb) b S::B::f
Breakpoint 1 at 0x400775: file t-class2.cc, line 25.
(gdb) b S::B::g
Breakpoint 2 at 0x400789: file t-class2.cc, line 26.
(gdb) r
Starting program: /home/dantipov/tmp/t-class2 

Breakpoint 1, S::B::f (this=0x7fffdb50, x=1) at t-class2.cc:25
25  virtual int f (int x) { return x + 4; }
(gdb) bt
#0  S::B::f (this=0x7fffdb50, x=1) at t-class2.cc:25
#1  0x00400643 in main (argc=1, argv=0x7fffdc68) at t-class2.cc:36
(gdb) p this
$1 = (S::B * const) 0x7fffdb50
(gdb) p *this
$2 = { = {_vptr.AS = 0x400840 , id0 = 333}, id1 =
444}
(gdb) c
Continuing.

Breakpoint 2, S::B::g (this=0x7fffdb50, x=1) at t-class2.cc:26
26  int g (int x) { return x + 14; }
(gdb) bt
#0  S::B::g (this=0x7fffdb50, x=1) at t-class2.cc:26
#1  0x00400669 in main (argc=1, argv=0x7fffdc68) at t-class2.cc:38
(gdb) p this
$3 = (S::B * const) 0x7fffdb50
(gdb) p *this
$4 = { = {_vptr.AS = 0x400840 , id0 = 333}, id1 =
444}

E.g. in calls to obj2.f () and obj2.g (), 'this' is 0x7fffdb50, and the
object
itself is {333, 444}.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type

[Dmitry Antipov via lldb-dev]

On 02/28/2018 11:31 AM, jonas echterhoff via lldb-dev wrote:


I'm using lldb-900.0.64.

^^
??
Latest official release is 5.0.1; also there are 6.0.0 (at -rc3, the next 
release)
and 7.0.0 (a.k.a SVN trunk). What's the 'version' output of your LLDB prompt?


Unfortunately, I have not yet succeeded in coming up with a small, independent 
repro case which shows this problem.


IIUC this is it:

struct A {
  int id0;
  A () { id0 = 111; }
  virtual int f (int x) { return x + 1; }
  int g (int x) { return x + 11; }
};

struct B: A {
  int id1;
  B () { id1 = 222; }
  virtual int f (int x) { return x + 2; }
  int g (int x) { return x + 12; }
};

namespace S {
  struct AS {
int id0;
AS () { id0 = 333; }
virtual int f (int x) { return x + 3; }
int g (int x) { return x + 13; }
  };
  struct B: AS {
int id1;
B () { id1 = 444; }
virtual int f (int x) { return x + 4; }
int g (int x) { return x + 14; }
  };
}

int main (int argc, char *argv[])
{
  B obj1;
  S::B obj2;
  return
obj1.f (argc) +
obj2.f (argc) +
obj1.g (argc) +
obj2.g (argc);
}

And in gdb, it is:

$ gdb -q t-class2
Reading symbols from t-class2...done.
(gdb) b S::B::f
Breakpoint 1 at 0x400775: file t-class2.cc, line 25.
(gdb) b S::B::g
Breakpoint 2 at 0x400789: file t-class2.cc, line 26.
(gdb) r
Starting program: /home/dantipov/tmp/t-class2

Breakpoint 1, S::B::f (this=0x7fffdb50, x=1) at t-class2.cc:25
25  virtual int f (int x) { return x + 4; }
(gdb) bt
#0  S::B::f (this=0x7fffdb50, x=1) at t-class2.cc:25
#1  0x00400643 in main (argc=1, argv=0x7fffdc68) at t-class2.cc:36
(gdb) p this
$1 = (S::B * const) 0x7fffdb50
(gdb) p *this
$2 = { = {_vptr.AS = 0x400840 , id0 = 333}, id1 = 
444}
(gdb) c
Continuing.

Breakpoint 2, S::B::g (this=0x7fffdb50, x=1) at t-class2.cc:26
26  int g (int x) { return x + 14; }
(gdb) bt
#0  S::B::g (this=0x7fffdb50, x=1) at t-class2.cc:26
#1  0x00400669 in main (argc=1, argv=0x7fffdc68) at t-class2.cc:38
(gdb) p this
$3 = (S::B * const) 0x7fffdb50
(gdb) p *this
$4 = { = {_vptr.AS = 0x400840 , id0 = 333}, id1 = 
444}

E.g. in calls to obj2.f () and obj2.g (), 'this' is 0x7fffdb50, and the 
object
itself is {333, 444}.

With lldb, it is:

$ /home/dantipov/.local/llvm-6.0.0/bin/lldb t-class2
(lldb) target create "t-class2"
Current executable set to 't-class2' (x86_64).
(lldb) breakpoint set -n S::B::f
Breakpoint 1: where = t-class2`S::B::f(int) at t-class2.cc:25, address = 
0x0040076a
(lldb) breakpoint set -n S::B::g
Breakpoint 2: where = t-class2`S::B::g(int) + 11 at t-class2.cc:26, address = 
0x00400789
(lldb) run
Process 5180 launched: '/home/dantipov/tmp/t-class2' (x86_64)
Process 5180 stopped
* thread #1, name = 't-class2', stop reason = breakpoint 1.1
frame #0: 0x0040076a t-class2`S::B::f(this=0x7fffdb50, x=1) 
at t-class2.cc:25
   22 struct B: AS {
   23   int id1;
   24   B () { id1 = 444; }
-> 25virtual int f (int x) { return x + 4; }
   26   int g (int x) { return x + 14; }
   27 };
   28   }
(lldb) bt
* thread #1, name = 't-class2', stop reason = breakpoint 1.1
  * frame #0: 0x0040076a t-class2`S::B::f(this=0x7fffdb50, x=1) 
at t-class2.cc:25
frame #1: 0x00400643 t-class2`main(argc=1, argv=0x7fffdc58) 
at t-class2.cc:36
frame #2: 0x7712000a libc.so.6`__libc_start_main(main=(t-class2`main at t-class2.cc:31), argc=1, argv=0x7fffdc58, init=, fini=, rtld_fini=, 
stack_end=0x7fffdc48) at libc-start.c:308

frame #3: 0x0040054a t-class2`_start + 42
(lldb) p this
(S::B *) $0 = 0x7fffdb50
(lldb) p *this
(S::B) $1 = {
  S::AS = (id0 = 111)
  id1 = 222
}
(lldb) c
Process 5180 resuming
Process 5180 stopped
* thread #1, name = 't-class2', stop reason = breakpoint 2.1
frame #0: 0x00400789 t-class2`S::B::g(this=0x7fffdb40, x=1) 
at t-class2.cc:26
   23   int id1;
   24   B () { id1 = 444; }
   25   virtual int f (int x) { return x + 4; }
-> 26int g (int x) { return x + 14; }
   27 };
   28   }
   29   
(lldb) bt
* thread #1, name = 't-class2', stop reason = breakpoint 2.1
  * frame #0: 0x00400789 t-class2`S::B::g(this=0x7fffdb40, x=1) 
at t-class2.cc:26
frame #1: 0x00400669 t-class2`main(argc=1, argv=0x7fffdc58) 
at t-class2.cc:38
frame #2: 0x7712000a libc.so.6`__libc_start_main(main=(t-class2`main at t-class2.cc:31), argc=1, argv=0x7fffdc58, init=, fini=, rtld_fini=, 
stack_end=0x7fffdc48) at libc-start.c:308

frame #3: 0x0040054a t-class2`_start + 42
(lldb) p this
(S::B *) $2 = 0x7fffdb40
(lldb) p *this
(S::B) $3 = {
  S::AS = (id0 = 333)
  id1 = 444
}

Here 'this' is different between calls to obj2.f () and obj2.g () 
(0x7fffdb50 vs.
0x7fffdb40), and objects are shown as 

[lldb-dev] lldb showing wrong type structure for virtual pointer type

[jonas echterhoff via lldb-dev]

Hi,

I'm having a problem where lldb will resolve the wrong type for virtual 
pointers, showing incorrect data for variables. This makes debugging our 
project very hard.

In our project, we commonly have the following structure:

class Transform : SomeParentClass
{
   virtual foo();
   void bar();
   /*...*/
}

namespace Scripting {
class Transform : SomeScriptingParentClass
{
   /*...*/
}
}

ie, we have native internal classes (like "Transform" in this case), and 
wrapper classes with identical names (but in a different namespace). (These are 
used to link the native class to a user facing API of the same name).

Now, when I put a breakpoint into "Transform::bar" and try to inspect the 
"this" variable, lldb shows "this" as a pointer to "Scripting::Transform" 
instead of as a pointer to "::Transform", thus showing the wrong data and 
making it impossible to inspect it's member variables. Since this is a common 
structure in our code, it makes debugging very hard.

Now, it seems that this is caused by Transform being a virtual class. So lldb 
will try to derive it's type at runtime by looking at the symbol name of the 
vtable (which is "__ZTV9Transform"). Then it will incorrectly map that to 
"Scripting::Transform" instead of "::Transform", which seems to be a bug in 
lldb.

I can work around the problem by patching the mach-o binary to remove the name 
of the vtable ("__ZTV9Transform") from the symbol table. Then lldb will be 
unable to look up the type dynamically at runtime, and use the dwarf info of 
the "bar" function, which specifies "this" to be a pointer to "::Transform". 
Obviously, this is a rather inconvenient workaround.

I guess I could rename the scripting representations of all our classes to use 
a different naming scheme (like "Scripting::_Transform"), but I'd only like to 
do that as a last resort.

I'm using lldb-900.0.64.
Unfortunately, I have not yet succeeded in coming up with a small, independent 
repro case which shows this problem.

So I'm wondering:
-Is this a known issue?
-Is there a fix?
-Any ideas for a better workaround?

Thanks for any help!

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