E.10 Remote Protocol Support for Non-Stop Mode

gdb's remote protocol supports non-stop debugging of multi-threaded programs, as described in Non-Stop Mode. If the stub supports non-stop mode, it should report that to gdb by including `QNonStop+' in its `qSupported' response (see qSupported).

gdb typically sends a `QNonStop' packet only when establishing a new connection with the stub. Entering non-stop mode does not alter the state of any currently-running threads, but targets must stop all threads in any already-attached processes when entering all-stop mode. gdb uses the `?' packet as necessary to probe the target state after a mode change.

In non-stop mode, when an attached process encounters an event that would otherwise be reported with a stop reply, it uses the asynchronous notification mechanism (see Notification Packets) to inform gdb. In contrast to all-stop mode, where all threads in all processes are stopped when a stop reply is sent, in non-stop mode only the thread reporting the stop event is stopped. That is, when reporting a `S' or `T' response to indicate completion of a step operation, hitting a breakpoint, or a fault, only the affected thread is stopped; any other still-running threads continue to run. When reporting a `W' or `X' response, all running threads belonging to other attached processes continue to run.

Only one stop reply notification at a time may be pending; if additional stop events occur before gdb has acknowledged the previous notification, they must be queued by the stub for later synchronous transmission in response to `vStopped' packets from gdb. Because the notification mechanism is unreliable, the stub is permitted to resend a stop reply notification if it believes gdb may not have received it. gdb ignores additional stop reply notifications received before it has finished processing a previous notification and the stub has completed sending any queued stop events.

Otherwise, gdb must be prepared to receive a stop reply notification at any time. Specifically, they may appear when gdb is not otherwise reading input from the stub, or when gdb is expecting to read a normal synchronous response or a `+'/`-' acknowledgment to a packet it has sent. Notification packets are distinct from any other communication from the stub so there is no ambiguity.

After receiving a stop reply notification, gdb shall acknowledge it by sending a `vStopped' packet (see vStopped packet) as a regular, synchronous request to the stub. Such acknowledgment is not required to happen immediately, as gdb is permitted to send other, unrelated packets to the stub first, which the stub should process normally.

Upon receiving a `vStopped' packet, if the stub has other queued stop events to report to gdb, it shall respond by sending a normal stop reply response. gdb shall then send another `vStopped' packet to solicit further responses; again, it is permitted to send other, unrelated packets as well which the stub should process normally.

If the stub receives a `vStopped' packet and there are no additional stop events to report, the stub shall return an `OK' response. At this point, if further stop events occur, the stub shall send a new stop reply notification, gdb shall accept the notification, and the process shall be repeated.

In non-stop mode, the target shall respond to the `?' packet as follows. First, any incomplete stop reply notification/`vStopped' sequence in progress is abandoned. The target must begin a new sequence reporting stop events for all stopped threads, whether or not it has previously reported those events to gdb. The first stop reply is sent as a synchronous reply to the `?' packet, and subsequent stop replies are sent as responses to `vStopped' packets using the mechanism described above. The target must not send asynchronous stop reply notifications until the sequence is complete. If all threads are running when the target receives the `?' packet, or if the target is not attached to any process, it shall respond `OK'.