4.9 Debugging Multiple Inferiors and Programs

gdb lets you run and debug multiple programs in a single
session. In addition, gdb on some systems may let you run
several programs simultaneously (otherwise you have to exit from one
before starting another). In the most general case, you can have
multiple threads of execution in each of multiple processes, launched
from multiple executables.

gdb represents the state of each program execution with an
object called an inferior. An inferior typically corresponds to
a process, but is more general and applies also to targets that do not
have processes. Inferiors may be created before a process runs, and
may be retained after a process exits. Inferiors have unique
identifiers that are different from process ids. Usually each
inferior will also have its own distinct address space, although some
embedded targets may have several inferiors running in different parts
of a single address space. Each inferior may in turn have multiple
threads running in it.

To find out what inferiors exist at any moment, use info inferiors:

info inferiors

Print a list of all inferiors currently being managed by gdb.

gdb displays for each inferior (in this order):

the inferior number assigned by gdb

the target system's inferior identifier

the name of the executable the inferior is running.

An asterisk ‘*’ preceding the gdb inferior number
indicates the current inferior.

Make inferior number infno the current inferior. The argument
infno is the inferior number assigned by gdb, as shown
in the first field of the ‘info inferiors’ display.

You can get multiple executables into a debugging session via the
add-inferior and clone-inferior commands. On some
systems gdb can add inferiors to the debug session
automatically by following calls to fork and exec. To
remove inferiors from the debugging session use the
remove-inferiors command.

add-inferior [ -copies n ] [ -exec executable ]

Adds n inferiors to be run using executable as the
executable; n defaults to 1. If no executable is specified,
the inferiors begins empty, with no program. You can still assign or
change the program assigned to the inferior at any time by using the
file command with the executable name as its argument.

clone-inferior [ -copies n ] [ infno ]

Adds n inferiors ready to execute the same program as inferior
infno; n defaults to 1, and infno defaults to the
number of the current inferior. This is a convenient command when you
want to run another instance of the inferior you are debugging.

Removes the inferior or inferiors infno.... It is not
possible to remove an inferior that is running with this command. For
those, use the kill or detach command first.

To quit debugging one of the running inferiors that is not the current
inferior, you can either detach from it by using the detach inferior command (allowing it to run independently), or kill it
using the kill inferiors command:

detach inferior infno...

Detach from the inferior or inferiors identified by gdb
inferior number(s) infno.... Note that the inferior's entry
still stays on the list of inferiors shown by info inferiors,
but its Description will show ‘<null>’.

kill inferiors infno...

Kill the inferior or inferiors identified by gdb inferior
number(s) infno.... Note that the inferior's entry still
stays on the list of inferiors shown by info inferiors, but its
Description will show ‘<null>’.

After the successful completion of a command such as detach,
detach inferiors, kill or kill inferiors, or after
a normal process exit, the inferior is still valid and listed with
info inferiors, ready to be restarted.

To be notified when inferiors are started or exit under gdb's
control use set print inferior-events:

set print inferior-events

set print inferior-events on

set print inferior-events off

The set print inferior-events command allows you to enable or
disable printing of messages when gdb notices that new
inferiors have started or that inferiors have exited or have been
detached. By default, these messages will not be printed.

show print inferior-events

Show whether messages will be printed when gdb detects that
inferiors have started, exited or have been detached.

Many commands will work the same with multiple programs as with a
single program: e.g., print myglobal will simply display the
value of myglobal in the current inferior.

Occasionaly, when debugging gdb itself, it may be useful to
get more info about the relationship of inferiors, programs, address
spaces in a debug session. You can do that with the maint info program-spaces command.

maint info program-spaces

Print a list of all program spaces currently being managed by
gdb.

gdb displays for each program space (in this order):

the program space number assigned by gdb

the name of the executable loaded into the program space, with e.g.,
the file command.

An asterisk ‘*’ preceding the gdb program space number
indicates the current program space.

In addition, below each program space line, gdb prints extra
information that isn't suitable to display in tabular form. For
example, the list of inferiors bound to the program space.

Here we can see that no inferior is running the program hello,
while process 21561 is running the program goodbye. On
some targets, it is possible that multiple inferiors are bound to the
same program space. The most common example is that of debugging both
the parent and child processes of a vfork call. For example,