[lldb-dev] debugserver inferior launch, stopped, $qC and $? thread not matching

Wed May 7 11:20:14 PDT 2014

> I have this implemented locally, just working through an issue where lldb
gets hung when attached to debugserver, waiting for the inferior's initial
state change to become stopped.

I tracked down my issue.  I just put up a [PATCH] for this.

On Wed, May 7, 2014 at 7:57 AM, Todd Fiala <tfiala at google.com> wrote:

> Hey Greg,
>
> I have this implemented locally, just working through an issue where lldb
> gets hung when attached to debugserver, waiting for the inferior's initial
> state change to become stopped.
>
> I'm seeing a few test failures as well, going back to top of tree to see
> if I'm introducing them.
>
> What's the best practice for using the output directory settings in Xcode?
>  Right now I'm using the
> ~/Library/Developer/Xcode/DerivedData/{some-generated-name-here} directory.
>  I'm then using a soft link to that directory as the '--executable=' part
> of the test runner.  What do you guys do for build output, and how do you
> run tests?
>
> Thanks!
>
> -Todd
>
>
> On Tue, May 6, 2014 at 11:42 AM, Todd Fiala <todd.fiala at gmail.com> wrote:
>
>> Ok.  I'll get that patched up and make sure all the tests passing before
>> are still passing afterwards.
>>
>>
>> On Tue, May 6, 2014 at 11:33 AM, Greg Clayton <gclayton at apple.com> wrote:
>>
>>>
>>> On May 6, 2014, at 10:58 AM, Todd Fiala <todd.fiala at gmail.com> wrote:
>>>
>>> > It appears gdbserver really returns the thread id as documented.
>>> >
>>> > Greg - I can get a patch together so we follow the documented protocol
>>> in lldb.  Before I look at that, is there any side effect you'd be
>>> concerned about with moving the $QC response to report the current
>>> thread-id?
>>>
>>> LLDB currently assumes that qC responds with the PID of the process. Any
>>> change we do will require a change over to using the qProcessInfo packet,
>>> and if the qProcessInfo doesn't work it should fall back onto the old qC
>>> packet behavior. All old debugserver binaries that are built into old iOS
>>> developer disk images still need to work, so we have to make sure we don't
>>> ruin that.
>>>
>>> So to fix this we should modify:
>>>
>>> GDBRemoteCommunicationClient::GetCurrentProcessID()
>>>
>>> to call GDBRemoteCommunicationClient::GetCurrentProcessInfo() and see if
>>> we have  process info. If we do, we will need to modify:
>>>
>>> GDBRemoteCommunicationClient::GetCurrentProcessInfo()
>>>
>>> to cache all of the returned (I don't see it caching the returned pid).
>>> Then we return the process ID if all goes well. Else we should fall back to
>>> returning the result of the "qC" packet for only for "arm*-apple-ios"
>>> targets just to make sure we don't break iOS.
>>>
>>>
>>> >
>>> > Thanks,
>>> > Todd
>>> >
>>> >
>>> > On Tue, May 6, 2014 at 8:27 AM, Todd Fiala <todd.fiala at gmail.com>
>>> wrote:
>>> > I see the issue.
>>> >
>>> > In debugserver and lldb-platform's impl (which llgs uses), qC is
>>> returning the process id.  I *think* this is wrong according to the gdb
>>> remote protocol, per the protocol documentation here:
>>> >
>>> > ‘qC’
>>> > Return the current thread ID.
>>> > Reply:
>>> >
>>> > ‘QC thread-id’
>>> > Where thread-id is a thread ID as documented in thread-id syntax.
>>> > ‘(anything else)’
>>> > Any other reply implies the old thread ID.
>>> >
>>> > This raises a general question.  If we have the protocol documented
>>> and we're not following it exactly (and provided the documentation isn't
>>> just plain wrong even for gdb), do we want to fix up lldb to match the
>>> protocol?  Or do we keep things the same, and document that we're deviating
>>> form the protocol as written?  I'd prefer to match the protocol for
>>> spec-following and iteroperability reasons.
>>> >
>>> > In the case of Linux, this issue wouldn't be discovered in the case of
>>> launching a process since the process id happens to also be the thread id
>>> of the first thread - hence this case the actual use of the pid instead of
>>> the tid in the $QC response packet wasn't detected.
>>> >
>>> > Let me know what you think and I'll fix it up (including the RNBRemote
>>> side).  I may swing over to gdb/gdbremote from MacOSX homebrew/MacPorts to
>>> see if gdb really uses the thread id or the process id - that will at least
>>> rule out if the docs are correct.
>>> >
>>> > -Todd
>>> >
>>> >
>>> > On Mon, May 5, 2014 at 10:45 PM, Todd Fiala <todd.fiala at gmail.com>
>>> wrote:
>>> > Hi Greg,
>>> >
>>> > I'm about to add a protocol-level test for llgs and debugserver that
>>> verifies that a launched inferior process's initial reported thread (i.e.
>>> response to $qC) is the same thread that reports when asking for stop state
>>> ($?), or at least that the thread-id is present in the threads listed when
>>> QListThreadsInStopReply is available.  What I'm finding on debugserver on
>>> MacOSX is that right after the successful launch with $A, the $qC query
>>> responds with a $QC{thread-id}.  The very next $?, though, without any
>>> intervening resume operation, lists the threads but doesn't contain the
>>> {thread-id} from the $QC.
>>> >
>>> > Here's a real transcript (with non-interesting bits removed).  It's
>>> from a debugserver started with no inferior, then attached to by lldb, then
>>> launching the first inferior process.
>>> >
>>> > ...
>>> > <lldb.driver.main-thread> <  27> send packet:
>>> $QListThreadsInStopReply#21
>>> > <lldb.driver.main-thread> <   6> read packet: $OK#00
>>> > <lldb.driver.main-thread> <  13> send packet: $qHostInfo#9b
>>> > <lldb.driver.main-thread> < 122> read packet:
>>> $cputype:16777223;cpusubtype:3;ostype:macosx;watchpoint_exceptions_received:after;vendor:apple;endian:little;ptrsize:8;#00
>>> > ...
>>> > <lldb.driver.main-thread> <  66> send packet:
>>> $A56,0,2f55736572732f746669616c612f706c61792f6370702f68656c6c6f#a0
>>> > <lldb.driver.main-thread> <   6> read packet: $OK#00
>>> > <lldb.driver.main-thread> <  18> send packet: $qLaunchSuccess#a5
>>> > <lldb.driver.main-thread> <   6> read packet: $OK#00
>>> > <lldb.driver.main-thread> <   6> send packet: $qC#b4
>>> > <lldb.driver.main-thread> <   9> read packet: $QC980#00   <<< Doesn't
>>> this say the app is launched, stopped, and thread-id 980 is selected?
>>> > <lldb.driver.main-thread> <   5> send packet: $?#3f
>>> > <lldb.driver.main-thread> < 503> read packet:
>>> $T11thread:63f5;qaddr:a0;threads:63f5;00:0000000000000000;01:0000000000000000;02:0000000000000000;03:0000000000000000;04:0000000000000000;05:0000000000000000;06:0000000000000000;07:68f8bf5fff7f0000;08:0000000000000000;09:0000000000000000;0a:0000000000000000;0b:0000000000000000;0c:0000000000000000;0d:0000000000000000;0e:0000000000000000;0f:0000000000000000;10:2810c05fff7f0000;11:0002000000000000;12:2b00000000000000;13:0000000000000000;14:0000000000000000;metype:5;mecount:2;medata:10003;medata:11;#00
>>> > ...
>>> >
>>> > The $? response seems to say it only has one thread, 63f5.  I would
>>> expect at least the 980 thread-id reported in the initial qC packet to
>>> exist somewhere.
>>> >
>>> > What am I missing?
>>> >
>>> > Thanks!
>>> >
>>> > --
>>> > -Todd
>>> >
>>> >
>>> >
>>> > --
>>> > -Todd
>>> >
>>> >
>>> >
>>> > --
>>> > -Todd
>>>
>>>
>>
>>
>> --
>> -Todd
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>

-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140507/29888031/attachment.html>