Re: [PATCH v2 19/29] stop_all_threads: (re-)enable async before waiting for stops

[Pedro Alves <pedro@palves.net>]

On 2022-07-21 7:21 p.m., Simon Marchi wrote:
>> @@ -5177,6 +5179,83 @@ handle_one (const wait_one_event &event)
>>    return false;
>>  }
>>  
>> +/* Helper for stop_all_threads.  wait_one waits for events until it
>> +   sees a TARGET_WAITKIND_NO_RESUMED event.  When it sees one, it
>> +   disables target_async for the target to stop waiting for events
>> +   from it.  TARGET_WAITKIND_NO_RESUMED can be delayed though,
>> +   consider, debugging against gdbserver:
>> +
>> +    #1 - Threads 1-5 are running, and thread 1 hits a breakpoint.
>> +
>> +    #2 - gdb processes the breakpoint hit for thread 1, stops all
>> +	 threads, and steps thread 1 over the breakpoint.  while
>> +	 stopping threads, some other threads reported interesting
>> +	 events, which were left pending in the thread's objects
>> +	 (infrun's queue).
>> +
>> +    #2 - Thread 1 exits (it stepped an exit syscall), and gdbserver
>> +	 reports the thread exit for thread 1.	The event ends up in
>> +	 remote's stop reply queue.
>> +
>> +    #3 - That was the last resumed thread, so gdbserver reports
>> +	 no-resumed, and that event also ends up in remote's stop
>> +	 reply queue, queued after the thread exit from #2.
> 
> I don't understand this part: why did gdbserver report two events
> here?  Why does it report a no-resumed event after reporting the
> thread-exited event?

gdbserver is tweaked to do that in the next patch:

  "[PATCH v2 20/29] gdbserver: Queue no-resumed event after thread exit"

If we didn't do that, then gdb would be forced to check whether the thread
that exited was the last one in non-stop mode, which would mean a a thread
list sync for every thread exit event.  Making sure to queue a no-resumed
event is a lot more efficient.