Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type
FWIW, I just out found that I can trivially work around this problem by
changing the order of object files passed to the linker.
It turns out that lldb will just pick up the first type named "Transform" in
the binary (regardless of namespace). Now, if I make sure that the object file
containing the "correct" Transform type comes first in the linker command line,
it will also be first in the binary, and it will be picked up by lldb. Now, in
theory, this might cause the same problem, just the "other way around", when
debugging code using the namespaced version of the type, but in our case, that
should not be a problem, because the latter is not a virtual type, so lldb
should not use dynamic lookup in that case.
jonas
> On Mar 1, 2018, at 3:59 AM, Jim Ingham wrote:
>
>
>
>> 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
[lldb-dev] 2018 European LLVM Developers’ Meeting -- The list of Talks
Hi, The list of Euro LLVM dev meeting technical talks, lightning talks, posters and BoFs is now available on the LLVM website. http://llvm.org/devmtg/2018-04/index.html#talks Get your tickets from: https://www.eventbrite.com/e/2018-european-llvm-developers-meeting-bristol-tickets-42283244322 If you are able to get to Bristol a day or two early, I recommend checking out the ACCU conference that is being held at the same venue throughout the week before our Dev Meeting. https://conference.accu.org/2018/ Thank you to all who submitted and thanks to all the reviewers. Hope to see you all in April at Bristol. -- Phillip Power ___ 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
Yes, the code was assuming that "exact_match" would be obeyed so it explicitly
specified returning only 1 match. When exact doesn't work, that means you get
the first one... You will only have a problem with the one whose name matches
both types, since the other way around the vtable name will have the namespace
in it, and it won't match the bare one. So your workaround should be good
altogether.
Jim
> On Mar 1, 2018, at 2:11 AM, jonas echterhoff wrote:
>
> FWIW, I just out found that I can trivially work around this problem by
> changing the order of object files passed to the linker.
>
> It turns out that lldb will just pick up the first type named "Transform" in
> the binary (regardless of namespace). Now, if I make sure that the object
> file containing the "correct" Transform type comes first in the linker
> command line, it will also be first in the binary, and it will be picked up
> by lldb. Now, in theory, this might cause the same problem, just the "other
> way around", when debugging code using the namespaced version of the type,
> but in our case, that should not be a problem, because the latter is not a
> virtual type, so lldb should not use dynamic lookup in that case.
>
> jonas
>
>> On Mar 1, 2018, at 3:59 AM, Jim Ingham wrote:
>>
>>
>>
>>> 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 c
[lldb-dev] LLDB/NetBSD - Status February 2018
I've managed to unbreak the LLDB debugger as much as possible with the current kernel and hit problems with ptrace(2) that are causing issues with further work on proper NetBSD support. Meanwhile, I've upstreamed all the planned NetBSD patches to sanitizers and helped other BSDs to gain better or initial support. http://blog.netbsd.org/tnf/entry/lldb_restoration_and_return_to Plan for the next milestone With the approaching NetBSD 8.0 release I plan to finish backporting a few changes there from HEAD: - Remove one unused feature from ptrace(2), PT_SET_SIGMASK & PT_GET_SIGMASK. I've originally introduced these operations with criu/rr-like software in mind, but they are misusing or even abusing ptrace(2) and are not regular process debuggers. I plan to remove this operation from HEAD and backport this to NetBSD-8(BETA), before the release, so no compat will be required for this call. Future ports of criu/rr should involve dedicated kernel support for such requirements. - Finish the backport of _UC_MACHINE_FP() to NetBSD-8. This will allow use of the same code in sanitizers in HEAD and NetBSD-8.0. - By popular demand, improve the regnsub(3) and regasub(3) API, adding support for more or less substitutions than 10. Once done, I will return to ptrace(2) debugging and corrections. signature.asc Description: OpenPGP digital signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
