gdb.texinfo patch

  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.


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
  

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"?
  

Luis Machado <lgustavo@codesourcery.com> wrote:

> 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.

[...]

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

I wasn't aware of that variable, so I don't know.  It will require some
investigation.  Certainly with non-stop mode turned on and may-interrupt
at the default value, it stops it.
  

On 05/15/2014 12:48 PM, David Taylor wrote:
> Luis Machado <lgustavo@codesourcery.com> wrote:
>
>> 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.
>
> [...]
>
>> Does GDB always want to stop the thread, even when "may-interrupt" is=20
>> set to "off"?
>
> I wasn't aware of that variable, so I don't know.  It will require some
> investigation.  Certainly with non-stop mode turned on and may-interrupt
> at the default value, it stops it.
>

Yeah. Unfortunately it is another one of those obscure settings. :-)

Given we have this option, it may be worth mentioning it in the piece 
you are patching, just for the sake of completeness. Otherwise folks may 
think GDB will always stop the threads when connecting.

It will stop most of the time anyway, since it is the default after all.

Luis
  

> From: David Taylor <dtaylor@emc.com>
> Date: Thu, 15 May 2014 11:25:10 -0400
> 
> 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.

Thanks.

> +@emph{Note: @value{GDBN} will send the qfThreadInfo query during the
                                          ^^^^^^^^^^^^
The packet name should be in @code.

> +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

Better make the second sentence part of the first (as in "..., and the
very first thread ...").

> +the qfThreadInfo reply is suitable for being stopped by @value{GDBN}.}
       ^^^^^^^^^^^^
@code

Otherwise, fine with me, assuming the contents is correct (I don't
know enough to say).
  

Here's the revised patch:

*** gdb.texinfo.~1.1.1.2.~	2014-02-18 10:36:03.000000000 -0500
--- gdb.texinfo	2014-05-15 13:50:23.000205000 -0400
***************
*** 39082,39087 ****
--- 39083,39094 ----
  Refer to @ref{thread-id syntax}, for the format of the @var{thread-id}
  fields.
  
+ @emph{Note: @value{GDBN} will send the @code{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 @code{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
  

> cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> Date: Thu, 15 May 2014 13:55:53 -0400
> From: David Taylor <dtaylor@emc.com>
> 
> Here's the revised patch:
> 
> *** gdb.texinfo.~1.1.1.2.~	2014-02-18 10:36:03.000000000 -0500
> --- gdb.texinfo	2014-05-15 13:50:23.000205000 -0400
> ***************
> *** 39082,39087 ****
> --- 39083,39094 ----
>   Refer to @ref{thread-id syntax}, for the format of the @var{thread-id}
>   fields.
>   
> + @emph{Note: @value{GDBN} will send the @code{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 @code{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

Thanks, I pushed this in your name.