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

[Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>]

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