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 <[email protected]> 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 <[email protected]> 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
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
