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

[Todd Fiala]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140506/8b0c66f2/attachment.html>