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:
- The target is now running. The thread field can be the global
thread ID of the the thread that is now running, and it 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.
- The target has stopped. The reason field can have one of the
- A breakpoint was reached.
- A watchpoint was triggered.
- A read watchpoint was triggered.
- An access watchpoint was triggered.
- An -exec-finish or similar CLI command was accomplished.
- An -exec-until or similar CLI command was accomplished.
- A watchpoint has gone out of scope.
- An -exec-next, -exec-next-instruction, -exec-step, -exec-step-instruction or
similar CLI command was accomplished.
- The inferior exited because of a signal.
- The inferior exited.
- The inferior exited normally.
- A signal was received by the inferior.
- The inferior has stopped due to a library being loaded or unloaded.
This can happen when
stop-on-solib-events (see Files) is
set or when a
catch load or
catch unload catchpoint is
in use (see Set Catchpoints).
- The inferior has forked. This is reported when
(see Set Catchpoints) has been used.
- The inferior has vforked. This is reported in when
(see Set Catchpoints) has been used.
- The inferior entered a system call. This is reported when
syscall (see Set Catchpoints) has been used.
- The inferior returned from a system call. This is reported when
catch syscall (see Set Catchpoints) has been used.
- The inferior called
exec. This is reported when
(see Set Catchpoints) has been used.
The id field identifies the global thread ID of 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
"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.
- 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.
- 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.
- 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. The code field is the exit code of the inferior; it exists
only when the inferior exited with some code.
- A thread either was created, or has exited. The id field
contains the global gdb identifier of the thread. The gid
field identifies the thread group this thread belongs to.
- Informs that the selected thread was changed as result of the last
command. This notification is not emitted as result of
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
- 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 is emitted only for backward compatibility
and should not be relied on to convey any useful information. 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
- 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
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
- Reports that the trace frame was changed and its new number is
tfnum. The number of the tracepoint associated with this trace
frame is tpnum.
- Reports that the new trace state variable name is created with
initial value initial.
- Reports that the trace state variable name is deleted or all
trace state variables are deleted.
- Reports that the trace state variable name is modified with
the initial value initial. The current value current of
trace state variable is optional and is reported if the current
value of trace state variable is known.
- Reports that a breakpoint was created, modified, or deleted,
respectively. Only user-visible breakpoints are reported to the MI
The bkpt argument is of the same form as returned by the various
breakpoint commands; See GDB/MI Breakpoint Commands. The
number is the ordinal number of the breakpoint.
Note that if a breakpoint is emitted in the result record of a
command, then it will not also be emitted in an async record.
- Execution log recording was either started or stopped on an
inferior. The id is the gdb identifier of the thread
group corresponding to the affected inferior.
The method field indicates the method used to record execution. If the
method in use supports multiple recording formats, format will be present
and contain the currently used format. See Process Record and Replay
for existing method and format values.
- Reports that a parameter of the command
set param is
changed to value. In the multi-word
the param is the whole parameter list to
For example, In command
set check type on, param
check type and value is
- Reports that bytes from addr to data + len were
written in an inferior. The id is the identifier of the
thread group corresponding to the affected inferior. The optional
type="code" part is reported if the memory written to holds