[lldb-dev] lldb showing wrong type structure for virtual pointer type
jonas echterhoff via lldb-dev
lldb-dev at lists.llvm.org
Wed Feb 28 12:03:13 PST 2018
> On Feb 28, 2018, at 7:14 PM, Jim Ingham <jingham at 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 at lists.llvm.org> wrote:
>>
>>
>>> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov <dantipov at 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 at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
More information about the lldb-dev
mailing list