[RFC][gdb/doc] Document non-stop attach behaviour

[RFC][gdb/doc] Document non-stop attach behaviour

[Tom de Vries]

Hi,

While investigating PR27908, I got confused about what the proper behaviour
is when attaching to a multi-threaded program in non-stop mode.

In particular, when running a script that issues an "info threads" after an
attach in non-stop mode, it can show a non-current thread as still running:
...
$ ./a.out & pid=$!; \
  gdb -q \
    -iex "set trace-commands on" \
    -iex "set pagination off" \
    -iex "set non-stop on" \
    -p $pid \
    -ex "info threads"
[2] 10038
+set pagination off
+set non-stop on
Attaching to process 10038
[New LWP 10040]
main () at test.c:37
37        while (1)
+info threads
  Id   Target Id                                 Frame
* 1    Thread 0x7f63547a8740 (LWP 10038) "a.out" main () at t.c:37
  2    Thread 0x7f6353fd7700 (LWP 10040) "a.out" (running)
(gdb)
Thread 2 "a.out" stopped.
thread_func (p=0x0) at test.c:13
13        while (1)
...

An "info threads" after the 'Thread 2 "a.out" stopped' message will show it as
stopped though:
...
info threads
+info threads
  Id   Target Id                                 Frame
* 1    Thread 0x7f63547a8740 (LWP 10038) "a.out" main () at t.c:37
  2    Thread 0x7f6353fd7700 (LWP 10040) "a.out" thread_func (p=0x0) at t.c:13
(gdb)
...

In conclusion, it seems that attaching in non-stop mode stops all threads,
just like in all-stop mode.  But the stopping of non-current threads is
visible to the user.

Update the non-stop documentation to describe the attach behaviour in some
detail.

Any comments?

Thanks,
- Tom

[gdb/doc] Document non-stop attach behaviour

gdb/doc/ChangeLog:

2021-06-07  Tom de Vries  <tdevries@suse.de>

	* gdb.texinfo (Non-Stop Mode): Describe non-stop attach behaviour.

---
 gdb/doc/gdb.texinfo | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index d09b86cda95..0fd7ab16150 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -6957,6 +6957,13 @@ one thread while allowing others to run freely, stepping
 one thread while holding all others stopped, or stepping several threads
 independently and simultaneously.
 
+Note that attaching in non-stop mode stops all threads, just as in
+all-stop mode.  However, while in all-stop mode the attach command is
+finished only once all threads are stopped, in non-stop mode it's
+finished once the current thread is stopped.  Consequently, it's
+briefly possible to observe non-current threads still running after an
+attach.
+
 To enter non-stop mode, use this sequence of commands before you run
 or attach to your program:
 

[PING][RFC][gdb/doc] Document non-stop attach behaviour

[Tom de Vries]

On 6/7/21 3:21 PM, Tom de Vries wrote:
> Hi,
> 
> While investigating PR27908, I got confused about what the proper behaviour
> is when attaching to a multi-threaded program in non-stop mode.
> 
> In particular, when running a script that issues an "info threads" after an
> attach in non-stop mode, it can show a non-current thread as still running:
> ...
> $ ./a.out & pid=$!; \
>   gdb -q \
>     -iex "set trace-commands on" \
>     -iex "set pagination off" \
>     -iex "set non-stop on" \
>     -p $pid \
>     -ex "info threads"
> [2] 10038
> +set pagination off
> +set non-stop on
> Attaching to process 10038
> [New LWP 10040]
> main () at test.c:37
> 37        while (1)
> +info threads
>   Id   Target Id                                 Frame
> * 1    Thread 0x7f63547a8740 (LWP 10038) "a.out" main () at t.c:37
>   2    Thread 0x7f6353fd7700 (LWP 10040) "a.out" (running)
> (gdb)
> Thread 2 "a.out" stopped.
> thread_func (p=0x0) at test.c:13
> 13        while (1)
> ...
> 
> An "info threads" after the 'Thread 2 "a.out" stopped' message will show it as
> stopped though:
> ...
> info threads
> +info threads
>   Id   Target Id                                 Frame
> * 1    Thread 0x7f63547a8740 (LWP 10038) "a.out" main () at t.c:37
>   2    Thread 0x7f6353fd7700 (LWP 10040) "a.out" thread_func (p=0x0) at t.c:13
> (gdb)
> ...
> 
> In conclusion, it seems that attaching in non-stop mode stops all threads,
> just like in all-stop mode.  But the stopping of non-current threads is
> visible to the user.
> 
> Update the non-stop documentation to describe the attach behaviour in some
> detail.
> 
> Any comments?
> 

Ping.

Thanks,
- Tom

> [gdb/doc] Document non-stop attach behaviour
> 
> gdb/doc/ChangeLog:
> 
> 2021-06-07  Tom de Vries  <tdevries@suse.de>
> 
> 	* gdb.texinfo (Non-Stop Mode): Describe non-stop attach behaviour.
> 
> ---
>  gdb/doc/gdb.texinfo | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index d09b86cda95..0fd7ab16150 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -6957,6 +6957,13 @@ one thread while allowing others to run freely, stepping
>  one thread while holding all others stopped, or stepping several threads
>  independently and simultaneously.
>  
> +Note that attaching in non-stop mode stops all threads, just as in
> +all-stop mode.  However, while in all-stop mode the attach command is
> +finished only once all threads are stopped, in non-stop mode it's
> +finished once the current thread is stopped.  Consequently, it's
> +briefly possible to observe non-current threads still running after an
> +attach.
> +
>  To enter non-stop mode, use this sequence of commands before you run
>  or attach to your program:
>  
> 

Re: [RFC][gdb/doc] Document non-stop attach behaviour

[Simon Marchi]

On 2021-06-07 9:21 a.m., Tom de Vries wrote:
> Hi,
> 
> While investigating PR27908, I got confused about what the proper behaviour
> is when attaching to a multi-threaded program in non-stop mode.
> 
> In particular, when running a script that issues an "info threads" after an
> attach in non-stop mode, it can show a non-current thread as still running:
> ...
> $ ./a.out & pid=$!; \
>   gdb -q \
>     -iex "set trace-commands on" \
>     -iex "set pagination off" \
>     -iex "set non-stop on" \
>     -p $pid \
>     -ex "info threads"
> [2] 10038
> +set pagination off
> +set non-stop on
> Attaching to process 10038
> [New LWP 10040]
> main () at test.c:37
> 37        while (1)
> +info threads
>   Id   Target Id                                 Frame
> * 1    Thread 0x7f63547a8740 (LWP 10038) "a.out" main () at t.c:37
>   2    Thread 0x7f6353fd7700 (LWP 10040) "a.out" (running)
> (gdb)
> Thread 2 "a.out" stopped.
> thread_func (p=0x0) at test.c:13
> 13        while (1)
> ...
> 
> An "info threads" after the 'Thread 2 "a.out" stopped' message will show it as
> stopped though:
> ...
> info threads
> +info threads
>   Id   Target Id                                 Frame
> * 1    Thread 0x7f63547a8740 (LWP 10038) "a.out" main () at t.c:37
>   2    Thread 0x7f6353fd7700 (LWP 10040) "a.out" thread_func (p=0x0) at t.c:13
> (gdb)
> ...
> 
> In conclusion, it seems that attaching in non-stop mode stops all threads,
> just like in all-stop mode.  But the stopping of non-current threads is
> visible to the user.
> 
> Update the non-stop documentation to describe the attach behaviour in some
> detail.
> 
> Any comments?
> 
> Thanks,
> - Tom
> 
> [gdb/doc] Document non-stop attach behaviour
> 
> gdb/doc/ChangeLog:
> 
> 2021-06-07  Tom de Vries  <tdevries@suse.de>
> 
> 	* gdb.texinfo (Non-Stop Mode): Describe non-stop attach behaviour.
> 
> ---
>  gdb/doc/gdb.texinfo | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index d09b86cda95..0fd7ab16150 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -6957,6 +6957,13 @@ one thread while allowing others to run freely, stepping
>  one thread while holding all others stopped, or stepping several threads
>  independently and simultaneously.
>  
> +Note that attaching in non-stop mode stops all threads, just as in
> +all-stop mode.  However, while in all-stop mode the attach command is
> +finished only once all threads are stopped, in non-stop mode it's
> +finished once the current thread is stopped.  Consequently, it's
> +briefly possible to observe non-current threads still running after an
> +attach.
> +
>  To enter non-stop mode, use this sequence of commands before you run
>  or attach to your program:
>  
> 

I think your patch describes well the current behaviour of GDB, so
that's good.

I think the behavior could be a bit more user friendly, we could wait
for all the attached program's threads to have reported their stop
before showing the prompt.  Same with the interrupt (with and without
"-a") command, we know which threads we expect to become stopped, we
could wait for them to be stopped before giving back the prompt.  That
would make it easier for scripts: when the attach / interrupt command
returns, you know the attached / interrupted threads are stopped and can
be inspected.

Simon

Re: [RFC][gdb/doc] Document non-stop attach behaviour

[Tom de Vries]

On 8/26/21 4:55 AM, Simon Marchi wrote:
> 
> 
> On 2021-06-07 9:21 a.m., Tom de Vries wrote:
>> Hi,
>>
>> While investigating PR27908, I got confused about what the proper behaviour
>> is when attaching to a multi-threaded program in non-stop mode.
>>
>> In particular, when running a script that issues an "info threads" after an
>> attach in non-stop mode, it can show a non-current thread as still running:
>> ...
>> $ ./a.out & pid=$!; \
>>   gdb -q \
>>     -iex "set trace-commands on" \
>>     -iex "set pagination off" \
>>     -iex "set non-stop on" \
>>     -p $pid \
>>     -ex "info threads"
>> [2] 10038
>> +set pagination off
>> +set non-stop on
>> Attaching to process 10038
>> [New LWP 10040]
>> main () at test.c:37
>> 37        while (1)
>> +info threads
>>   Id   Target Id                                 Frame
>> * 1    Thread 0x7f63547a8740 (LWP 10038) "a.out" main () at t.c:37
>>   2    Thread 0x7f6353fd7700 (LWP 10040) "a.out" (running)
>> (gdb)
>> Thread 2 "a.out" stopped.
>> thread_func (p=0x0) at test.c:13
>> 13        while (1)
>> ...
>>
>> An "info threads" after the 'Thread 2 "a.out" stopped' message will show it as
>> stopped though:
>> ...
>> info threads
>> +info threads
>>   Id   Target Id                                 Frame
>> * 1    Thread 0x7f63547a8740 (LWP 10038) "a.out" main () at t.c:37
>>   2    Thread 0x7f6353fd7700 (LWP 10040) "a.out" thread_func (p=0x0) at t.c:13
>> (gdb)
>> ...
>>
>> In conclusion, it seems that attaching in non-stop mode stops all threads,
>> just like in all-stop mode.  But the stopping of non-current threads is
>> visible to the user.
>>
>> Update the non-stop documentation to describe the attach behaviour in some
>> detail.
>>
>> Any comments?
>>
>> Thanks,
>> - Tom
>>
>> [gdb/doc] Document non-stop attach behaviour
>>
>> gdb/doc/ChangeLog:
>>
>> 2021-06-07  Tom de Vries  <tdevries@suse.de>
>>
>> 	* gdb.texinfo (Non-Stop Mode): Describe non-stop attach behaviour.
>>
>> ---
>>  gdb/doc/gdb.texinfo | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
>> index d09b86cda95..0fd7ab16150 100644
>> --- a/gdb/doc/gdb.texinfo
>> +++ b/gdb/doc/gdb.texinfo
>> @@ -6957,6 +6957,13 @@ one thread while allowing others to run freely, stepping
>>  one thread while holding all others stopped, or stepping several threads
>>  independently and simultaneously.
>>  
>> +Note that attaching in non-stop mode stops all threads, just as in
>> +all-stop mode.  However, while in all-stop mode the attach command is
>> +finished only once all threads are stopped, in non-stop mode it's
>> +finished once the current thread is stopped.  Consequently, it's
>> +briefly possible to observe non-current threads still running after an
>> +attach.
>> +
>>  To enter non-stop mode, use this sequence of commands before you run
>>  or attach to your program:
>>  
>>
> 
> I think your patch describes well the current behaviour of GDB, so
> that's good.
> 
> I think the behavior could be a bit more user friendly, we could wait
> for all the attached program's threads to have reported their stop
> before showing the prompt.  Same with the interrupt (with and without
> "-a") command, we know which threads we expect to become stopped, we
> could wait for them to be stopped before giving back the prompt.  That
> would make it easier for scripts: when the attach / interrupt command
> returns, you know the attached / interrupted threads are stopped and can
> be inspected.

Ack, I can file a PR for that.

So, should I apply the doc patch, or is it f.i.i too trivial to mention?

Thanks,
- Tom

Re: [RFC][gdb/doc] Document non-stop attach behaviour

[Tom de Vries]

On 8/26/21 12:08 PM, Tom de Vries wrote:
> On 8/26/21 4:55 AM, Simon Marchi wrote:
>>
>> I think the behavior could be a bit more user friendly, we could wait
>> for all the attached program's threads to have reported their stop
>> before showing the prompt.  Same with the interrupt (with and without
>> "-a") command, we know which threads we expect to become stopped, we
>> could wait for them to be stopped before giving back the prompt.  That
>> would make it easier for scripts: when the attach / interrupt command
>> returns, you know the attached / interrupted threads are stopped and can
>> be inspected.
> 
> Ack, I can file a PR for that.
> 

Filed PR https://sourceware.org/bugzilla/show_bug.cgi?id=28270.

Thanks,
- Tom