4 在GDB中运行程序
在gdb下运行程序时,首先在编译程序的时候要产生调试信息,然后在某个环境中带参数启动gdb。如果是调试本地程序,还可以重定向程序的输入输出,调试已经运行的进程或者杀死一个子进程。
4.1 为调试编译程序
为了能够调试程序,首先要在编译程序的时候产生调试信息。这些调试信息保存在目标文件中,描述了每个变量的数据类型、函数以及源代码的行号对应可执行代码地址。在编译的时候,给编译器指定‘-g’选项就可以产生调试信息。程序发布的时候,可能编译器会被加上‘-O’选项编译,然后交给客户。但是,有些编译器无法同时处理‘-g’和‘-O’选项。所以在使用这些编译器的时候,无法在优化过的可执行代码中包含调试信息。GNU C/C++编译器gcc可以同时支持‘-g’和‘-O’选项。因此,可以调试用gcc优化过的可执行代码。人们可能会认为他们的程序是程序的,但是这种幸运是无法断定的,因此推荐大家在任何时候都使用‘-g’选项编译程序。更多的信息,可参加优化过的代码 。老版本的GNU C编译器使用‘-gg’选项产生调试信息。GDB不再支持这种格式。如果你的GNU C编译器支持这种选项,不要使用它。gdb识别预处理宏并且可以展示宏的展开形式。大多数编译器在只指定‘-g’选项的时候,调试信息里并没有包含预处理宏的信息,因为这类信息非常庞大。版本3.1以及之后的gcc,调试信息中包含宏信息,只要在编译的时候指定‘-gdwarf-2’ 和‘-g3’选项。 前一个选项会使调试信息满足Dwarf 2格式,而后一个选现则使调试信息中含有“额外的信息”。将来,我们希望会有更精简的方式产生宏信息,这样只要给编译器指定‘-g’选项就可以了。
4.2 启动程序
-
run
r
在gdb中用run命令启动程序。 首先指定程序名及其参数传给gdb(参加启动和退出gdb)或者执行文件的命令(参加指定文件的命令)。
If you are running your program in an execution environment that supports processes, run
creates an inferior process and makes that process run your program. In some environments without processes, run
jumps to the start of your program. Other targets, like `remote ', are always running. If you get an error message like this one:
“远程”目标不支持“run”命令。
尝试“help target“ 或者 ”continue“。
然后使用”continue“继续运行程序。You may needload
first (see load
).
The execution of a program is affected by certain information it receives from its superior. gdb provides ways to specify this information, which you must do before starting your program. (You can change it after starting your program, but such changes only affect your program the next time you start it.) This information may be divided into four categories:
-
The
arguments.
-
Specify the arguments to give your program as the arguments of the
run
command. If a shell is available on your target, the shell is used to pass the arguments, so that you may use normal conventions (such as wildcard expansion or variable substitution) in describing the arguments. In Unix systems, you can control which shell is used with theSHELL
environment variable. See Your Program's Arguments .
The
environment.
-
Your program normally inherits its environment from
gdb , but you can use the
gdb commands
set environment
andunset environment
to change parts of the environment that affect your program. See Your Program's Environment .
The
working directory.
-
Your program inherits its working directory from
gdb . You can set the
gdb working directory with the
cd
command in gdb . See Your Program's Working Directory .
The
standard input and output.
-
Your program normally uses the same device for standard input and standard output as
gdb is using. You can redirect input and output in the
run
command line, or you can use thetty
command to set a different device for your program. See Your Program's Input and Output .Warning: While input and output redirection work, you cannot use pipes to pass the output of the program you are debugging to another program; if you attempt this, gdb is likely to wind up debugging the wrong program.
When you issue the run
command, your program begins to execute immediately. See Stopping and Continuing , for discussion of how to arrange for your program to stop. Once your program has stopped, you may call functions in your program, using the print
or call
commands. See Examining Data .
If the modification time of your symbol file has changed since the last time gdb read its symbols, gdb discards its symbol table, and reads it again. When it does this, gdb tries to retain your current breakpoints.
-
The name of the main procedure can vary from language to language. With C or C
++ , the main procedure name is always
main
, but other languages such as Ada do not require a specific name for their main procedure. The debugger provides a convenient way to start the execution of the program and to stop at the beginning of the main procedure, depending on the language used.The `start ' command does the equivalent of setting a temporary breakpoint at the beginning of the main procedure and then invoking the `run ' command.
Some programs contain an elaboration phase where some startup code is executed before the main procedure is called. This depends on the languages used to write your program. In C++ , for instance, constructors for static and global objects are executed before
main
is called. It is therefore possible that the debugger stops before reaching the main procedure. However, the temporary breakpoint will remain to halt execution.Specify the arguments to give to your program as arguments to the `start ' command. These arguments will be given verbatim to the underlying `run ' command. Note that the same arguments will be reused if no argument is provided during subsequent calls to `start ' or `run '.
It is sometimes necessary to debug the program during elaboration. In these cases, using the
start
command would stop the execution of your program too late, as the program would have already completed the elaboration phase. Under these circumstances, insert breakpoints in your elaboration code before running your program. -
When `
exec-wrapper ' is set, the specified wrapper is used to launch programs for debugging.
gdb starts your program with a shell command of the form
exec
wrapper
program . Quoting is added to
program and its arguments, but not to
wrapper , so you should add quotes if appropriate for your shell. The wrapper runs until it executes your program, and then
gdb takes control.
You can use any program that eventually calls
execve
with its arguments as a wrapper. Several standard Unix utilities do this, e.g.env
andnohup
. Any Unix shell script ending withexec "$@"
will also work.For example, you can use
env
to pass an environment variable to the debugged program, without setting the variable in your shell's environment:(gdb) set exec-wrapper env 'LD_PRELOAD=libtest.so'
(gdb) runThis command is available when debugging locally on most targets, excluding djgpp , Cygwin, MS Windows, and QNX Neutrino.
-
This option (enabled by default in
gdb ) will turn off the native randomization of the virtual address space of the started program. This option is useful for multiple debugging sessions to make the execution better reproducible and memory addresses reusable across debugging sessions.
This feature is implemented only on gnu /Linux. You can get the same behavior using
(gdb) set exec-wrapper setarch `uname -m` -R
-
Leave the behavior of the started executable unchanged. Some bugs rear their ugly heads only when the program is loaded at certain addresses. If your bug disappears when you run the program under
gdb , that might be because
gdb by default disables the address randomization on platforms, such as
gnu /Linux, which do that for stand-alone programs. Use
set disable-randomization off to try to reproduce such elusive bugs.
The virtual address space randomization is implemented only on gnu /Linux. It protects the programs against some kinds of security attacks. In these cases the attacker needs to know the exact location of a concrete executable code. Randomizing its location makes it impossible to inject jumps misusing a code at its expected addresses.
Prelinking shared libraries provides a startup performance advantage but it makes addresses in these libraries predictable for privileged processes by having just unprivileged access at the target system. Reading the shared library binary gives enough information for assembling the malicious code misusing it. Still even a prelinked shared library can get loaded at a new random address just requiring the regular relocation process during the startup. Shared libraries not already prelinked are always loaded at a randomly chosen address.
Position independent executables (PIE) contain position independent code similar to the shared libraries and therefore such executables get loaded at a randomly chosen address upon startup. PIE executables always load even already prelinked shared libraries at a random address. You can build such executable using gcc -fPIE -pie .
Heap (malloc storage), stack and custom mmap areas are always placed randomly (as long as the randomization is enabled).
- Show the current setting of the explicit disable of the native randomization of the virtual address space of the started program.
-
start
set exec-wrapper
wrapper
show exec-wrapper
unset exec-wrapper
set disable-randomization
set disable-randomization on
set disable-randomization off
show disable-randomization
4.3 参数
The arguments to your program can be specified by the arguments of the run
command. They are passed to a shell, which expands wildcard characters and performs redirection of I/O, and thence to your program. Your SHELL
environment variable (if it exists) specifies what shell gdb uses. If you do not define SHELL
, gdb uses the default shell (/bin/sh on Unix).
On non-Unix systems, the program is usually invoked directly by gdb , which emulates I/O redirection via the appropriate system calls, and the wildcard characters are expanded by the startup code of the program, not by the shell.
run
with no arguments uses the same arguments used by the previous run
, or those set by the set args
command.
-
Specify the arguments to be used the next time your program is run. If
set args
has no arguments,run
executes your program with no arguments. Once you have run your program with arguments, usingset args
before the nextrun
is the only way to run it again without arguments. - Show the arguments to give your program when it is started.
set args
show args
4.4 环境
The environment consists of a set of environment variables and their values. Environment variables conventionally record such things as your user name, your home directory, your terminal type, and your search path for programs to run. Usually you set up environment variables with the shell and they are inherited by all the other programs you run. When debugging, it can be useful to try running your program with a modified environment without having to start gdb over again.
-
Add
directory to the front of the
PATH
environment variable (the search path for executables) that will be passed to your program. The value ofPATH
used by gdb does not change. You may specify several directory names, separated by whitespace or by a system-dependent separator character (` : ' on Unix, ` ; ' on MS-DOS and MS-Windows). If directory is already in the path, it is moved to the front, so it is searched sooner.You can use the string `$cwd ' to refer to whatever is the current working directory at the time gdb searches the path. If you use `. ' instead, it refers to the directory where you executed the
path
command. gdb replaces `. ' in the directory argument (with the current path) before adding directory to the search path. -
Display the list of search paths for executables (the
PATH
environment variable). -
Print the value of environment variable
varname to be given to your program when it starts. If you do not supply
varname , print the names and values of all environment variables to be given to your program. You can abbreviate
environment
asenv
. -
Set environment variable
varname to
value . The value changes for your program only, not for
gdb itself.
value may be any string; the values of environment variables are just strings, and any interpretation is supplied by your program itself. The
value parameter is optional; if it is eliminated, the variable is set to a null value.
For example, this command:
set env USER = foo
tells the debugged program, when subsequently run, that its user is named `foo '. (The spaces around `= ' are used for clarity here; they are not actually required.)
-
Remove variable
varname from the environment to be passed to your program. This is different from `
set env varname = ';
unset environment
removes the variable from the environment, rather than assigning it an empty value.
path
directory
show paths
show environment
[
varname
]
set environment
varname
[
=
value
]
unset environment
varname
Warning: On Unix systems, gdb runs your program using the shell indicated by your SHELL
environment variable if it exists (or /bin/sh
if not). If your SHELL
variable names a shell that runs an initialization file—such as .cshrc for C-shell, or .bashrc for BASH—any variables you set in that file affect your program. You may wish to move setting of environment variables to files that are only run when you sign on, such as .login or .profile .
4.5 工作目录
Each time you start your program with run
, it inherits its working directory from the current working directory of gdb . The gdb working directory is initially whatever it inherited from its parent process (typically the shell), but you can specify a new working directory in gdb with the cd
command.
The gdb working directory also serves as a default for the commands that specify files for gdb to operate on. See Commands to Specify Files .
-
Set the
gdb working directory to
directory .
- Print the gdb working directory.
cd
directory
pwd
It is generally impossible to find the current working directory of the process being debugged (since a program can change its directory during its run). If you work on a system where gdb is configured with the /proc support, you can use the info proc
command (see SVR4 Process Information ) to find out the current working directory of the debuggee.
4.6 输入输出
By default, the program you run under gdb does input and output to the same terminal that gdb uses. gdb switches the terminal to its own terminal modes to interact with you, but it records the terminal modes your program was using and switches back to them when you continue running your program.
- Displays information recorded by gdb about the terminal modes your program is using.
info terminal
You can redirect your program's input and/or output using shell redirection with the run
command. For example,
run > outfile
starts your program, diverting its output to the file outfile .
Another way to specify where your program should do input and output is with thetty
command. This command accepts a file name as argument, and causes this file to be the default for futurerun
commands. It also resets the controlling terminal for the child process, for futurerun
commands. For example,
tty /dev/ttyb
directs that processes started with subsequentrun
commands default to do input and output on the terminal /dev/ttyb
and have that as their controlling terminal.
An explicit redirection inrun
overrides thetty
command's
effect on the input/output device, but not its effect on the controlling
terminal.
When you use thetty
command or redirect input in therun
command, only the input for your program
is affected. The input
for gdb
still comes from your terminal.tty
is an alias
forset inferior-tty
.
You can use theshow inferior-tty
command to tell gdb
to
display the name of the terminal that will be used for future runs of your
program.
set inferior-tty /dev/ttyb
Set the tty for the program being debugged to /dev/ttyb.Show the current tty for the program being debugged.
show inferior-tty
4.7 调试已经运行的程序
-
This command attaches to a running process—one that was started outside
gdb . (
info files
shows your active targets.) The command takes as argument a process ID. The usual way to find out the process-id of a Unix process is with theps
utility, or with the ` jobs -l ' shell command.attach
does not repeat if you press <RET> a second time after executing the command.
attach
process-id
To use attach
, your program must be running in an environment which supports processes; for example, attach
does not work for programs on bare-board targets that lack an operating system. You must also have permission to send the process a signal.
When you use attach
, the debugger finds the program running in the process first by looking in the current working directory, then (if the program is not found) by using the source file search path (see Specifying Source Directories ). You can also use the file
command to load the program. See Commands to Specify Files .
The first thing gdb does after arranging to debug the specified process is to stop it. You can examine and modify an attached process with all the gdb commands that are ordinarily available when you start processes with run
. You can insert breakpoints; you can step and continue; you can modify storage. If you would rather the process continue running, you may use the continue
command after attaching gdb to the process.
-
When you have finished debugging the attached process, you can use the
detach
command to release it from gdb control. Detaching the process continues its execution. After thedetach
command, that process and gdb become completely independent once more, and you are ready toattach
another process or start one withrun
.detach
does not repeat if you press <RET> again after executing the command.
detach
If you exit gdb while you have an attached process, you detach that process. If you use the run
command, you kill that process. By default, gdb asks for confirmation if you try to do either of these things; you can control whether or not you need to confirm by using the set confirm
command (see Optional Warnings and Messages ).
4.8 杀死子进程
- Kill the child process in which your program is running under gdb .
kill
This command is useful if you wish to debug a core dump instead of a running process. gdb ignores any core dump file while your program is running.
On some operating systems, a program cannot be executed outside gdb while you have breakpoints set on it inside gdb . You can use the kill
command in this situation to permit running your program outside the debugger.
The kill
command is also useful if you wish to recompile and relink your program, since on many systems it is impossible to modify an executable file while it is running in a process. In this case, when you next type run
, gdb notices that the file has changed, and reads the symbol table again (while trying to preserve your current breakpoint settings).
4.9 调试多进程
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
:
-
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.
For example,
info inferiors
(gdb) info inferiors
Num Description Executable
2 process 2307 hello
* 1 process 3401 goodbye
To switch focus between inferiors, use theinferior
command:
- 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.
inferior
infno
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-inferior
command.
-
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. -
Adds
n inferiors ready to execute the same program as inferior
infno .
n defaults 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-inferior
infno
-
Removes the inferior
infno . It is not possible to remove an inferior that is running with this command. For those, use the
kill
ordetach
command first.
add-inferior [ -copies
n
] [ -exec
executable
]
clone-inferior [ -copies
n
] [
infno
]
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 inferior
command:
-
Detach from the inferior identified by
gdb inferior number
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 the inferior identified by
gdb inferior number
infno . Note that the inferior's entry still stays on the list of inferiors shown by
info inferiors
, but its Description will show ` <null> '.
detach inferior
infno
kill inferior
infno
After the successful completion of a command such as detach
, detach inferior
, kill
or kill inferior
, 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
:
-
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 whether messages will be printed when gdb detects that inferiors have started, exited or have been detached.
set print inferior-events
set print inferior-events on
set print inferior-events off
show print inferior-events
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.
-
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.
(gdb) maint info program-spaces
Id Executable
2 goodbye
Bound inferiors: ID 1 (process 21561)
* 1 helloHere we can see that no inferior is running the program
hello
, whileprocess 21561
is running the programgoodbye
. 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 avfork
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
vfork
call.
maint info program-spaces
4.10 调试多线程
In some operating systems, such as HP-UX and Solaris, a single program may have more than one thread of execution. The precise semantics of threads differ from one operating system to another, but in general the threads of a single program are akin to multiple processes—except that they share one address space (that is, they can all examine and modify the same variables). On the other hand, each thread has its own registers and execution stack, and perhaps private memory.
gdb provides these facilities for debugging multi-thread programs:
- automatic notification of new threads
- `thread threadno ', a command to switch among threads
- `info threads ', a command to inquire about existing threads
- `thread apply [ threadno ] [ all ] args ', a command to apply a command to a list of threads
- thread-specific breakpoints
- `set print thread-events ', which controls printing of messages on thread start and exit.
- `set libthread-db-search-path path ', which lets the user specify which
libthread_db
to use if the default choice isn't compatible with the program.
Warning: These facilities are not yet available on every gdb configuration where the operating system supports threads. If your gdb does not support threads, these commands have no effect. For example, a system without thread support shows no output from ` info threads ', and always rejects thethread
command, like this:(gdb) thread 1
Thread ID 1 not known. Use the "info threads" command to see the IDs of currently known threads.
(gdb) info threads
The gdb thread debugging facility allows you to observe all threads while your program runs—but whenever gdb takes control, one thread in particular is always the focus of debugging. This thread is called the current thread . Debugging commands show program information from the perspective of the current thread.
Whenever gdb detects a new thread in your program, it displays the target system's identification for the thread with a message in the form `[New systag ] '. systag is a thread identifier whose form varies depending on the particular system. For example, on gnu /Linux, you might see
[New Thread 46912507313328 (LWP 25582)]
when gdb
notices a new thread. In contrast, on an SGI system,
the systag
is simply something like `p
', with no
further qualifier.
For debugging purposes, gdb associates its own thread number—always a single integer—with each thread in your program.
-
Display a summary of all threads currently in your program.
gdb displays for each thread (in this order):
- the thread number assigned by gdb
- the target system's thread identifier (systag )
- the thread's name, if one is known. A thread can either be named by the user (see
thread name
, below), or, in some cases, by the program itself. - the current stack frame summary for that thread
An asterisk `* ' to the left of the gdb thread number indicates the current thread.
For example,
info threads
(gdb) info threads
Id Target Id Frame
3 process 35 thread 27 0x34e5 in sigpause ()
2 process 35 thread 23 0x34e5 in sigpause ()
* 1 process 35 thread 13 main (argc=1, argv=0x7ffffff8)
at threadtest.c:68
On Solaris, you can display more information about user threads with a Solaris-specific command:
- Display info on Solaris user threads.
maint info sol-threads
-
Make thread number
threadno the current thread. The command argument
threadno is the internal
gdb thread number, as shown in the first field of the `
info threads ' display.
gdb responds by displaying the system identifier of the thread you selected, and its current stack frame summary:
(gdb) thread 2
[Switching to thread 2 (Thread 0xb7fdab70 (LWP 12747))]
#0 some_function (ignore=0x0) at example.c:8
8 printf ("hello/n");As with the `[New ...] ' message, the form of the text after `Switching to ' depends on your system's conventions for identifying threads.
The debugger convenience variable `$_thread ' contains the number of the current thread. You may find this useful in writing breakpoint conditional expressions, command scripts, and so forth. See See Convenience Variables , for general information on convenience variables.
-
The
thread apply
command allows you to apply the named command to one or more threads. Specify the numbers of the threads that you want affected with the command argument threadno . It can be a single thread number, one of the numbers shown in the first field of the ` info threads ' display; or it could be a range of thread numbers, as in2-4
. To apply a command to all threads, type thread apply all command . -
This command assigns a name to the current thread. If no argument is given, any existing user-specified name is removed. The thread name appears in the `
info threads ' display.
On some systems, such as gnu /Linux, gdb is able to determine the name of the thread as given by the OS. On these systems, a name specified with `thread name ' will override the system-give name, and removing the user-specified name will cause gdb to once again display the system-specified name.
-
The
set print thread-events
command allows you to enable or disable printing of messages when gdb notices that new threads have started or that threads have exited. By default, these messages will be printed if detection of these events is supported by the target. Note that these messages cannot be disabled on all targets. - Show whether messages will be printed when gdb detects that threads have started and exited.
thread
threadno
thread apply [
threadno
| all]
command
thread name [
name
]
set print thread-events
set print thread-events on
set print thread-events off
show print thread-events
See Stopping and Starting Multi-thread Programs , for more information about how gdb behaves when you stop and start programs with multiple threads.
See Setting Watchpoints , for information about watchpoints in programs with multiple threads.
-
If this variable is set,
path is a colon-separated list of directories
gdb will use to search for
libthread_db
. If you omit path , ` libthread-db-search-path ' will be reset to an empty list.On gnu /Linux and Solaris systems, gdb uses a “helper”
libthread_db
library to obtain information about threads in the inferior process. gdb will use `libthread-db-search-path ' to findlibthread_db
. If that fails, gdb will continue with default system shared library directories, and finally the directory from whichlibpthread
was loaded in the inferior process.For any
libthread_db
library gdb finds in above directories, gdb attempts to initialize it with the current inferior process. If this initialization fails (which could happen because of a version mismatch betweenlibthread_db
andlibpthread
), gdb will unloadlibthread_db
, and continue with the next directory. If none oflibthread_db
libraries initialize successfully, gdb will issue a warning and thread debugging will be disabled.Setting
libthread-db-search-path
is currently implemented only on some platforms. -
Display current libthread_db search path.
-
Turns on or off display of
libthread_db
-related events. Use1
to enable,0
to disable.
set libthread-db-search-path
[
path
]
show libthread-db-search-path
set debug libthread-db
show debug libthread-db
4.11 调试Forks
On most systems, gdb has no special support for debugging programs which create additional processes using the fork
function. When a program forks, gdb will continue to debug the parent process and the child process will run unimpeded. If you have set a breakpoint in any code which the child then executes, the child will get a SIGTRAP
signal which (unless it catches the signal) will cause it to terminate.
However, if you want to debug the child process there is a workaround which isn't too painful. Put a call to sleep
in the code which the child process executes after the fork. It may be useful to sleep only if a certain environment variable is set, or a certain file exists, so that the delay need not occur when you don't want to run gdb on the child. While the child is sleeping, use the ps
program to get its process ID. Then tell gdb (a new invocation of gdb if you are also debugging the parent process) to attach to the child process (see Attach ). From that point on you can debug the child process just like any other process which you attached to.
On some systems, gdb provides support for debugging programs that create additional processes using the fork
or vfork
functions. Currently, the only platforms with this feature are HP-UX (11.x and later only?) and gnu /Linux (kernel version 2.5.60 and later).
By default, when a program forks, gdb will continue to debug the parent process and the child process will run unimpeded.
If you want to follow the child process instead of the parent process, use the command set follow-fork-mode
.
-
Set the debugger response to a program call of
fork
orvfork
. A call tofork
orvfork
creates a new process. The mode argument can be:-
The original process is debugged after a fork. The child process runs unimpeded. This is the default.
- The new process is debugged after a fork. The parent process runs unimpeded.
parent
child
-
The original process is debugged after a fork. The child process runs unimpeded. This is the default.
-
Display the current debugger response to a
fork
orvfork
call.
set follow-fork-mode
mode
show follow-fork-mode
On Linux, if you want to debug both the parent and child processes, use the command set detach-on-fork
.
-
Tells gdb whether to detach one of the processes after a fork, or retain debugger control over them both.
-
The child process (or parent process, depending on the value of
follow-fork-mode
) will be detached and allowed to run independently. This is the default.
-
Both processes will be held under the control of
gdb . One process (child or parent, depending on the value of
follow-fork-mode
) is debugged as usual, while the other is held suspended.
on
off
-
The child process (or parent process, depending on the value of
- Show whether detach-on-fork mode is on/off.
set detach-on-fork
mode
show detach-on-fork
If you choose to set `detach-on-fork ' mode off, then gdb will retain control of all forked processes (including nested forks). You can list the forked processes under the control of gdb by using the info inferiors
command, and switch from one fork to another by using the inferior
command (see Debugging Multiple Inferiors and Programs ).
To quit debugging one of the forked processes, you can either detach from it by using the detach inferior
command (allowing it to run independently), or kill it using the kill inferior
command. See Debugging Multiple Inferiors and Programs .
If you ask to debug a child process and a vfork
is followed by an exec
, gdb executes the new target up to the first breakpoint in the new target. If you have a breakpoint set on main
in your original program, the breakpoint will also be set on the child process's main
.
On some systems, when a child process is spawned by vfork
, you cannot debug the child or parent until an exec
call completes.
If you issue a run
command to gdb after an exec
call executes, the new target restarts. To restart the parent process, use the file
command with the parent executable name as its argument. By default, after an exec
call executes, gdb discards the symbols of the previous executable image. You can change this behaviour with the set follow-exec-mode
command.
-
Set debugger response to a program call of
exec
. Anexec
call replaces the program image of a process.follow-exec-mode
can be:-
gdb creates a new inferior and rebinds the process to this new inferior. The program the process was running before the
exec
call can be restarted afterwards by restarting the original inferior.For example:
1 <null> prog1
same
(gdb) info inferiors
(gdb) info inferior
Id Description Executable
* 1 <null> prog1
(gdb) run
process 12020 is executing new program: prog2
Program exited normally.
(gdb) info inferiors
Id Description Executable
* 2 <null> prog2 -
gdb keeps the process bound to the same inferior. The new executable image replaces the previous executable loaded in the inferior. Restarting the inferior after the
exec
call, with e.g., therun
command, restarts the executable the process was running after theexec
call. This is the default mode.For example:
(gdb) info inferiors
Id Description Executable
* 1 <null> prog1
(gdb) run
process 12020 is executing new program: prog2
Program exited normally.
(gdb) info inferiors
Id Description Executable
* 1 <null> prog2
new
-
gdb creates a new inferior and rebinds the process to this new inferior. The program the process was running before the
set follow-exec-mode
mode
You can use the catch
command to make gdb stop whenever a fork
, vfork
, or exec
call is made. See Setting Catchpoints .
4.12 设置书签
On certain operating system1 , gdb is able to save a snapshot of a program's state, called a checkpoint , and come back to it later.
Returning to a checkpoint effectively undoes everything that has happened in the program since the checkpoint
was saved. This includes changes in memory, registers, and even (within some limits) system state. Effectively, it is like going back in time to the moment when the checkpoint was saved.
Thus, if you're stepping thru a program and you think you're getting close to the point where things go wrong, you can save a checkpoint. Then, if you accidentally go too far and miss the critical statement, instead of having to restart your program from the beginning, you can just go back to the checkpoint and start again from there.
This can be especially useful if it takes a lot of time or steps to reach the point where you think the bug occurs.
To use the checkpoint
/restart
method of debugging:
-
Save a snapshot of the debugged program's current execution state. The
checkpoint
command takes no arguments, but each checkpoint is assigned a small integer id, similar to a breakpoint id. -
List the checkpoints that have been saved in the current debugging session. For each checkpoint, the following information will be listed:
Checkpoint ID
Process ID
Code Address
Source line, or label
-
-
Restore the program state that was saved as checkpoint number
checkpoint-id . All program variables, registers, stack frames etc. will be returned to the values that they had when the checkpoint was saved. In essence, gdb will “wind back the clock” to the point in time when the checkpoint was saved.
Note that breakpoints, gdb variables, command history etc. are not affected by restoring a checkpoint. In general, a checkpoint only restores things that reside in the program being debugged, not in the debugger.
- Delete the previously-saved checkpoint identified by checkpoint-id .
checkpoint
info checkpoints
restart
checkpoint-id
delete checkpoint
checkpoint-id
Returning to a previously saved checkpoint will restore the user state of the program being debugged, plus a significant subset of the system (OS) state, including file pointers. It won't “un-write” data from a file, but it will rewind the file pointer to the previous location, so that the previously written data can be overwritten. For files opened in read mode, the pointer will also be restored so that the previously read data can be read again.
Of course, characters that have been sent to a printer (or other external device) cannot be “snatched back”, and characters received from eg. a serial device can be removed from internal program buffers, but they cannot be “pushed back” into the serial pipeline, ready to be received again. Similarly, the actual contents of files that have been changed cannot be restored (at this time).
However, within those constraints, you actually can “rewind” your program to a previously saved point in time, and begin debugging it again — and you can change the course of events so as to debug a different execution path this time.
Finally, there is one bit of internal program state that will be different when you return to a checkpoint — the program's process id. Each checkpoint will have a unique process id (or pid ), and each will be different from the program's original pid . If your program has saved a local copy of its process id, this could potentially pose a problem.
4.12.1 A Non-obvious Benefit of Using Checkpoints
On some systems such as gnu /Linux, address space randomization is performed on new processes for security reasons. This makes it difficult or impossible to set a breakpoint, or watchpoint, on an absolute address if you have to restart the program, since the absolute location of a symbol will change from one execution to the next.
A checkpoint, however, is an identical copy of a process. Therefore if you create a checkpoint at (eg.) the start of main, and simply return to that checkpoint instead of restarting the process, you can avoid the effects of address randomization and your symbols will all stay in the same place.