In writing a new stub (to replace our old stub), I have discovered what
I believe to be the rule for how GDB chooses which thread to stop during
the initial connection. Knowing this sooner would have saved my some
grief. Hoping to help the next person avoid that same grief, here's a
patch (as a unified diff against gdb/doc/gdb.texinfo of GDB 7.7) to
document it.
It adds text to the discussion of the qfThreadInfo / qsThreadInfo
messages.
Index: gdb/doc/gdb.texinfo
===================================================================
RCS file: /home/cvsroot/GDB/gdb/doc/gdb.texinfo,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 gdb.texinfo
--- gdb/doc/gdb.texinfo 18 Feb 2014 15:36:03 -0000 1.1.1.2
+++ gdb/doc/gdb.texinfo 15 May 2014 15:11:23 -0000
@@ -39082,6 +39083,12 @@
Refer to @ref{thread-id syntax}, for the format of the @var{thread-id}
fields.
+@emph{Note: @value{GDBN} will send the qfThreadInfo query during the
+initial connection with the remote target. And the very first thread ID
+mentioned in the reply will be stopped by @value{GDBN} in a subsequent
+message. Therefore the stub should ensure that the first thread ID in
+the qfThreadInfo reply is suitable for being stopped by @value{GDBN}.}
+
@item qGetTLSAddr:@var{thread-id},@var{offset},@var{lm}
@cindex get thread-local storage address, remote request
@cindex @samp{qGetTLSAddr} packet
EMC has a copyright assignment on file (though I don't think this is big
enough to have an issue). I do not have commit privileges, so if it is
deemed suitable for inclusion, someone else will have to do the deed.
David
--
David Taylor
dtaylor@emc.com