#### 27.5.3 gdb/mi Async Records

Async records are used to notify the gdb/mi client of additional changes that have occurred. Those changes can either be a consequence of gdb/mi commands (e.g., a breakpoint modified) or a result of target activity (e.g., target stopped).

The following is the list of possible async records:

`*running,thread-id="`thread`"`
  The target is now running. The thread field tells which specific thread is now running, and can be ‘`all`’ if all threads are running. The frontend should assume that no interaction with a running thread is possible after this notification is produced. The frontend should not assume that this notification is output only once for any command. gdb may emit this notification several times, either for different threads, because it cannot resume all threads together, or even for a single thread, if the thread must be stepped though some code before letting it run freely.
`*stopped,reason="`reason`",thread-id="`id`",stopped-threads="`stopped`",core="`core`"`
  The target has stopped. The reason field can have one of the following values:
  `breakpoint-hit`
    A breakpoint was reached.
  `watchpoint-trigger`
    A watchpoint was triggered.
  `read-watchpoint-trigger`
    A read watchpoint was triggered.
  `access-watchpoint-trigger`
    An access watchpoint was triggered.
  `function-finished`
    An -exec-finish or similar CLI command was accomplished.
  `location-reached`
    An -exec-until or similar CLI command was accomplished.
  `watchpoint-scope`
    A watchpoint has gone out of scope.
  `end-stepping-range`
    An -exec-next, -exec-next-instruction, -exec-step, -exec-step-instruction or similar CLI command was accomplished.
  `exited-signalled`
    The inferior exited because of a signal.
  `exited`
    The inferior exited.
  `exited-normally`
    The inferior exited normally.
  `signal-received`
    A signal was received by the inferior.

  The id field identifies the thread that directly caused the stop – for example by hitting a breakpoint. Depending on whether all-stop mode is in effect (see All-Stop Mode), gdb may either stop all threads, or only the thread that directly triggered the stop. If all threads are stopped, the stopped field will have the value of `"all"`. Otherwise, the value of the stopped field will be a list of thread identifiers. Presently, this list will always include a single thread, but frontend should be prepared to see several threads in the list. The core field reports the processor core on which the stop event has happened. This field may be absent if such information is not available.

`=thread-group-added,id="`id`"`
`=thread-group-removed,id="`id`"`
  A thread group was either added or removed. The id field contains the gdb identifier of the thread group. When a thread group is added, it generally might not be associated with a running process. When a thread group is removed, its id becomes invalid and cannot be used in any way.
`=thread-group-started,id="`id`",pid="`pid`"`
  A thread group became associated with a running program, either because the program was just started or the thread group was attached to a program. The id field contains the gdb identifier of the thread group. The pid field contains process identifier, specific to the operating system.
`=thread-group-exited,id="`id`"`
  A thread group is no longer associated with a running program, either because the program has exited, or because it was detached from. The id field contains the gdb identifier of the thread group.
`=thread-created,id="`id`",group-id="`gid`"`
`=thread-exited,id="`id`",group-id="`gid`"`
  A thread either was created, or has exited. The id field contains the gdb identifier of the thread. The gid field identifies the thread group this thread belongs to.
`=thread-selected,id="`id`"`
  Informs that the selected thread was changed as result of the last command. This notification is not emitted as result of `-thread-select` command but is emitted whenever an MI command that is not documented to change the selected thread actually changes it. In particular, invoking, directly or indirectly (via user-defined command), the CLI `thread` command, will generate this notification.

  We suggest that in response to this notification, front ends highlight the selected thread and cause subsequent commands to apply to that thread.

`=library-loaded,...`
  Reports that a new library file was loaded by the program. This notification has 4 fields—id, target-name, host-name, and symbols-loaded. The id field is an opaque identifier of the library. For remote debugging case, target-name and host-name fields give the name of the library file on the target, and on the host respectively. For native debugging, both those fields have the same value. The symbols-loaded field reports if the debug symbols for this library are loaded. The thread-group field, if present, specifies the id of the thread group in whose context the library was loaded. If the field is absent, it means the library was loaded in the context of all present thread groups.
`=library-unloaded,...`
  Reports that a library was unloaded by the program. This notification has 3 fields—id, target-name and host-name with the same meaning as for the `=library-loaded` notification. The thread-group field, if present, specifies the id of the thread group in whose context the library was unloaded. If the field is absent, it means the library was unloaded in the context of all present thread groups.