<div dir="ltr">It appears gdbserver really returns the thread id as documented.<div><br></div><div>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?</div>
<div><br></div><div>Thanks,</div><div>Todd</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 6, 2014 at 8:27 AM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I see the issue.<div><br></div><div>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 <a href="https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets" target="_blank">here</a>:</div>
<div><br></div><div><dl><dt style="color:rgb(0,0,0);font-family:Times;font-size:medium">‘<samp><span>qC</span></samp>’</dt><dd><font color="#000000" face="Times" size="3"><a name="145d2258389b5057_index-current-thread_002c-remote-request-2805"></a><a name="145d2258389b5057_index-g_t_0040samp_007bqC_007d-packet-2806"></a>Return the current thread ID.</font><p style="color:rgb(0,0,0);font-family:Times;font-size:medium">
Reply:</p><dl><dt style="color:rgb(0,0,0);font-family:Times;font-size:medium">‘<samp><span>QC </span><var>thread-id</var></samp>’</dt><dd style="color:rgb(0,0,0);font-family:Times;font-size:medium">Where <var>thread-id</var> is a thread ID as documented in <a href="https://sourceware.org/gdb/onlinedocs/gdb/thread_002did-syntax.html#thread_002did-syntax" target="_blank">thread-id syntax</a>. <br>
</dd><dt style="color:rgb(0,0,0);font-family:Times;font-size:medium">‘<samp><span>(anything else)</span></samp>’</dt><dd style="color:rgb(0,0,0);font-family:Times;font-size:medium">Any other reply implies the old thread ID.</dd>
<dd style="color:rgb(0,0,0);font-family:Times;font-size:medium"><br></dd></dl></dd></dl></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Todd<div><div class="h5"><br><br><div class="gmail_quote">On Mon, May 5, 2014 at 10:45 PM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Greg,<div><br></div><div><div>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.</div>
<div><div><br></div><div>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.</div>
<div>
<br></div><div>...</div><div><div><lldb.driver.main-thread> < 27> send packet: $QListThreadsInStopReply#21<br></div><div><lldb.driver.main-thread> < 6> read packet: $OK#00</div><div><lldb.driver.main-thread> < 13> send packet: $qHostInfo#9b</div>
<div><lldb.driver.main-thread> < 122> read packet: $cputype:16777223;cpusubtype:3;ostype:macosx;watchpoint_exceptions_received:after;vendor:apple;endian:little;ptrsize:8;#00</div><div>...</div><div><lldb.driver.main-thread> < 66> send packet: $A56,0,2f55736572732f746669616c612f706c61792f6370702f68656c6c6f#a0<br>
</div><div><lldb.driver.main-thread> < 6> read packet: $OK#00</div><div><lldb.driver.main-thread> < 18> send packet: $qLaunchSuccess#a5</div><div><lldb.driver.main-thread> < 6> read packet: $OK#00</div>
<div><lldb.driver.main-thread> < 6> send packet: $qC#b4</div><div><lldb.driver.main-thread> < 9> <b>read packet: $QC980#00</b> <<< Doesn't this say the app is launched, stopped, and thread-id 980 is selected?</div>
<div><lldb.driver.main-thread> < 5> send packet: $?#3f</div><div><lldb.driver.main-thread> < 503> read packet: $T11<b>thread:63f5</b>;qaddr:a0;<b>threads:63f5</b>;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</div>
</div><div>...</div><div><br></div><div>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.</div><div><br></div><div>
What am I missing?</div><div><br></div><div>Thanks!</div></div><span><font color="#888888"><div><br></div>-- <br><div dir="ltr">-Todd</div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div dir="ltr">-Todd</div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">-Todd</div>
</div>