• Aucun résultat trouvé

Debugging Multiple Inferiors and Programs

Dans le document Debugging with gdb (Page 48-51)

4 Running Programs Under gdb

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):

1. the inferior number assigned by gdb 2. the target system’s inferior identifier

3. the name of the executable the inferior is running.

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

For example,

(gdb) info inferiors

Num Description Executable 2 process 2307 hello

* 1 process 3401 goodbye

To switch focus between inferiors, use the inferiorcommand:

inferiorinfno

Make inferior numberinfnothe current inferior. The argumentinfnois the infe-rior number assigned bygdb, 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 systemsgdb can add inferiors to the debug session automatically by following calls toforkand exec. To remove inferiors from the debugging session use theremove-inferiors command.

add-inferior [ -copiesn] [ -exec executable]

Adds ninferiors 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 thefile command with the executable name as its argument.

clone-inferior [ -copiesn] [infno ]

Adds n inferiors ready to execute the same program as inferior infno. n de-faults to 1. 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.

(gdb) info inferiors

Num Description Executable

* 1 process 29964 helloworld (gdb) clone-inferior

Added inferior 2.

1 inferiors added.

(gdb) info inferiors

Num Description Executable 2 <null> helloworld

* 1 process 29964 helloworld

You can now simply switch focus to inferior 2 and run it.

remove-inferiors infno...

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 ordetach 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 inferiorinfno...

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 asdetach,detach inferiors,kill orkill 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 myglobalwill simply display the value of myglobalin 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 themaint info program-spacescommand.

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):

1. the program space number assigned bygdb

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

An asterisk ‘*’ preceding thegdbprogram 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.

(gdb) maint info program-spaces Id Executable

2 goodbye

Bound inferiors: ID 1 (process 21561)

* 1 hello

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,

(gdb) maint info program-spaces Id Executable

* 1 vfork-test

Bound inferiors: ID 2 (process 18050), ID 1 (process 18045)

Here, both inferior 2 and inferior 1 are running in the same program space as a result of inferior 1 having executed a vforkcall.

Dans le document Debugging with gdb (Page 48-51)