Next: General Query Packets, Previous: Packets, Up: Remote Protocol

### E.3 Stop Reply Packets

The ‘`C`’, ‘`c`’, ‘`S`’, ‘`s`’, ‘`vCont`’, ‘`vAttach`’, ‘`vRun`’, ‘`vStopped`’, and ‘`?`’ packets can receive any of the below as a reply. Except for ‘`?`’ and ‘`vStopped`’, that reply is only returned when the target halts. In the below the exact meaning of signal number is defined by the header `include/gdb/signals.h` in the gdb source code.

As in the description of request packets, we include spaces in the reply templates for clarity; these are not part of the reply packet's syntax. No gdb stop reply packet uses spaces to separate its components.

‘`S AA`’
  The program received signal number AA (a two-digit hexadecimal number). This is equivalent to a ‘`T`’ response with no n:r pairs.
‘`T AA n1:r1;n2:r2;...`’
  The program received signal number AA (a two-digit hexadecimal number). This is equivalent to an ‘`S`’ response, except that the ‘`n:r`’ pairs can carry values of important registers and other information directly in the stop reply packet, reducing round-trip latency. Single-step and breakpoint traps are reported this way. Each ‘`n:r`’ pair is interpreted as follows:
  - If n is a hexadecimal number, it is a register number, and the corresponding r gives that register's value. The data r is a series of bytes in target byte order, with each byte given by a two-digit hex number.
  - If n is ‘`thread`’, then r is the thread-id of the stopped thread, as specified in thread-id syntax.
  - If n is ‘`core`’, then r is the hexadecimal number of the core on which the stop event was detected.
  - If n is a recognized stop reason, it describes a more specific event that stopped the target. The currently defined stop reasons are listed below. The aa should be ‘`05`’, the trap signal. At most one stop reason should be present.
  - Otherwise, gdb should ignore this ‘`n:r`’ pair and go on to the next; this allows us to extend the protocol in the future.

  The currently defined stop reasons are:

  ‘`watch`’
  ‘`rwatch`’
  ‘`awatch`’
    The packet indicates a watchpoint hit, and r is the data address, in hex.

  ‘`library`’
    The packet indicates that the loaded libraries have changed. gdb should use ‘`qXfer:libraries:read`’ to fetch a new list of loaded libraries. The r part is ignored.

  ‘`replaylog`’
    The packet indicates that the target cannot continue replaying logged execution events, because it has reached the end (or the beginning when executing backward) of the log. The value of r will be either ‘`begin`’ or ‘`end`’. See Reverse Execution, for more information.
‘`W AA`’
‘`W AA ; process:pid`’
  The process exited, and AA is the exit status. This is only applicable to certain targets.

  The second form of the response, including the process ID of the exited process, can be used only when gdb has reported support for multiprocess protocol extensions; see multiprocess extensions. The pid is formatted as a big-endian hex string.

‘`X AA`’
‘`X AA ; process:pid`’
  The process terminated with signal AA.

  The second form of the response, including the process ID of the terminated process, can be used only when gdb has reported support for multiprocess protocol extensions; see multiprocess extensions. The pid is formatted as a big-endian hex string.

‘`O XX...`’
  ‘`XX...`’ is hex encoding of ascii data, to be written as the program's console output. This can happen at any time while the program is running and the debugger should continue to wait for ‘`W`’, ‘`T`’, etc. This reply is not permitted in non-stop mode.
‘`F call-id,parameter...`’
  call-id is the identifier which says which host system call should be called. This is just the name of the function. Translation into the correct system call is only applicable as it's defined in gdb. See File-I/O Remote Protocol Extension, for a list of implemented system calls.

  ‘`parameter...`’ is a list of parameters as defined for this very system call.

  The target replies with this packet when it expects gdb to call a host system call on behalf of the target. gdb replies with an appropriate ‘`F`’ packet and keeps up waiting for the next reply packet from the target. The latest ‘`C`’, ‘`c`’, ‘`S`’ or ‘`s`’ action is expected to be continued. See File-I/O Remote Protocol Extension, for more details.