On some targets, gdb is capable of processing MI commands
even while the target is running. This is called asynchronous
command execution (see Background Execution). The frontend may
specify a preferrence for asynchronous execution using the
-gdb-set mi-async 1 command, which should be emitted before
either running the executable or attaching to the target. After the
frontend has started the executable or attached to the target, it can
find if asynchronous execution is enabled using the
-gdb-set mi-async on
-gdb-set mi-async off
off, which is the default, MI execution commands (e.g.,
-exec-continue) are foreground commands, and gdb waits
for the program to stop before processing further commands.
on, MI execution commands are background execution
-exec-continue becomes the equivalent of the
c& CLI command), and so gdb is capable of processing
MI commands even while the target is running.
Note: In gdb version 7.7 and earlier, this option was called
target-async instead of
mi-async, and it had the effect
of both putting MI in asynchronous mode and making CLI background
commands possible. CLI background commands are now always possible
“out of the box” if the target supports them. The old spelling is
kept as a deprecated alias for backwards compatibility.
Even if gdb can accept a command while target is running, many commands that access the target do not work when the target is running. Therefore, asynchronous command execution is most useful when combined with non-stop mode (see Non-Stop Mode). Then, it is possible to examine the state of one thread, while other threads are running.
When a given thread is running, MI commands that try to access the
target in the context of that thread may not work, or may work only on
some targets. In particular, commands that try to operate on thread's
stack will not work, on any target. Commands that read memory, or
modify breakpoints, may work or not work, depending on the target. Note
that even commands that operate on global state, such as
set, and breakpoint commands, still access the target in the
context of a specific thread, so frontend should try to find a
stopped thread and perform the operation on that thread (using the
Which commands will work in the context of a running thread is
highly target dependent. However, the two commands
-exec-interrupt, to stop a thread, and
to find the state of a thread, will always work.