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:
<SOME_ADDRESS>: static-type = '<STATIC_TYPE>' has vtable symbol 'vtable for
<DYNAMIC_CLASS>'
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 <jo...@unity3d.com> wrote:
>
>
>
>> On Feb 28, 2018, at 7:14 PM, Jim Ingham <jing...@apple.com> 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
>>> <lldb-dev@lists.llvm.org> wrote:
>>>
>>>
>>>> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov <danti...@nvidia.com> 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
>>> 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
