Remote Non-Stop - Debugging with GDB
Description: Debugging with GDB

Next: Packet Acknowledgment, Previous: Notification Packets, Up: Remote Protocol

### 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.

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`’.