gdb.texinfo patch

[Luis Machado]

On 05/15/2014 12:25 PM, David Taylor wrote:
> 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
>
>

Does GDB always want to stop the thread, even when "may-interrupt" is 
set to "off"?