Re: Async + all-stop mode for gdbserver

Hi!

On 2024-05-26 01:57, Yibo Yan via Gdb wrote:
> Hi,
> 
> I am working on a project to support a unified view for debugging
> distributed systems, and I am using gdbserver to be attached to the remote
> processes.
> 
> I need to use gdbserver with `mi-async on` and `non-stop off`, which seems
> to work correctly with gdb, but this is not the case when the gdb is
> connected to the gdbserver.
> 
> One simple use case here is to list all thread information (-thread-info)
> when the target is running. The command gets executed correctly when the
> gdb is locally attached to a running process and returns the list of thread
> information. When the gdb is remotely connected to the gdbserver, the
> behavior is not consistent, as it doesn't allow me to run `-thread-info`
> anymore.
> 
> Looking at the design of RSP, I can tell it doesn't have a specific packet
> for enabling async mode besides `QNonStop` for enabling non-stop mode.
> Looks like the source code of gdbserver also indicates the same thing ---
> the async mode is only enabled when the non-stop mode is enabled.
> 
> My question is whether this is intended behavior or potentially a design
> flaw or bug? I am aware that I can still manually interrupt and resume all
> threads to mimic the behavior of async + all-stop. I am just wondering if I
> can achieve the same thing directly from gdbserver instead of hacking it
> this way.
> 
> Many thanks!

It's intended, but unfortunately, the transition was never completed.  If you do
"maint set target-non-stop on" before connecting, then the remote connection with use
QNonStop to enable non-stop, and with "set non-stop off", GDB will handle the stopping
all threads and resuming them all for you.  We call this "all-stop on top of non-stop".

Ideally we'd get to a point where GDB would enable this automatically if the remote end
supports it, but we haven't done that because the non-stop variant of the protocol is
missing a few things.  Off the top of my head:

 - async version of "O" replies.

 - Async File I/O (https://sourceware.org/gdb/current/onlinedocs/gdb.html/File_002dI_002fO-Overview.html)

 - optional: look into aggregation of stop replies, so that the server could
   say "thread 1 stopped for TRAP, all other threads suspended", explicitly without
   requiring one stop reply per thread.

If you don't care about async "O" replies and File I/O, which I'd bet you don't, since
these matter more for embedded targets, then you should be good with just enabling
"maint set target-non-stop on".  The Linux native target already works that way (backend
always in non-stop mode), btw.

Pedro Alves