> On Feb 28, 2018, at 9:27 PM, Jim Ingham <jing...@apple.com> 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:
>
> <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?
0x000000010f62ecd0: static-type = 'Transform *' has vtable symbol 'vtable for
Transform'
0x000000010f62ecd0: static-type = 'Transform *' has dynamic type:
uid={0x100012d7a}, type-name='Transform'
jonas
>
> 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
