27.1.2 Asynchronous command execution and non-stop mode

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
-list-target-features command.

-gdb-set mi-async on

-gdb-set mi-async off

Set whether MI is in asynchronous mode.

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

When on, MI execution commands are background execution
commands (e.g., -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.

-gdb-show mi-async

Show whether MI asynchronous mode is enabled.

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 print,
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
‘--thread’ option).

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 -thread-info,
to find the state of a thread, will always work.