> On Feb 28, 2018, at 7:14 PM, Jim Ingham <[email protected]> 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 = 0x000000010fe2eb20
That gives me the wrong namespace
(lldb) print this
(Scripting::UnityEngine::Transform *) $4 = 0x000000010fe2eb20
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 = 0x000000010fe2eb20
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
>> <[email protected]> wrote:
>>
>>
>>> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov <[email protected]> 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 ()
>>> (0x00007fffffffdb50 vs.
>>> 0x00007fffffffdb40), 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
>> [email protected]
>> 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
