Next: Thread groups, Previous: Context management, Up: GDB/MI General Design
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 target-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.
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.