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

[Todd Fiala]

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?

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<https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets>
> :
>
> ‘qC’Return the current thread ID.
>
> Reply:
> ‘QC thread-id’Where thread-id is a thread ID as documented in thread-id
> syntax<https://sourceware.org/gdb/onlinedocs/gdb/thread_002did-syntax.html#thread_002did-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: $T11*thread: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140506/4206d677/attachment.html>