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

[Simon Marchi <simon.marchi@polymtl.ca>]

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