| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When you run a program under GDB, you must first generate debugging information when you compile it.
You may start GDB with its arguments, if any, in an environment of your choice. If you are doing native debugging, you may redirect your program's input and output, debug an already running process, or kill a child process.
4.1 Compiling for Debugging Compiling for debugging 4.2 Starting your Program Starting your program 4.3 Your Program's Arguments Your program's arguments 4.4 Your Program's Environment Your program's environment
4.5 Your Program's Working Directory Your program's working directory 4.6 Your Program's Input and Output Your program's input and output 4.7 Debugging an Already-running Process Debugging an already-running process 4.8 Killing the Child Process Killing the child process
4.9 Debugging Multiple Inferiors and Programs Debugging multiple inferiors and programs 4.10 Debugging Programs with Multiple Threads Debugging programs with multiple threads 4.11 Debugging Forks Debugging forks 4.12 Setting a Bookmark to Return to Later Setting a bookmark to return to later
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In order to debug a program effectively, you need to generate debugging information when you compile it. This debugging information is stored in the object file; it describes the data type of each variable or function and the correspondence between source line numbers and addresses in the executable code.
To request debugging information, specify the `-g' option when you run the compiler.
Programs that are to be shipped to your customers are compiled with optimizations, using the `-O' compiler option. However, some compilers are unable to handle the `-g' and `-O' options together. Using those compilers, you cannot generate optimized executables containing debugging information.
GCC, the GNU C/C++ compiler, supports `-g' with or without `-O', making it possible to debug optimized code. We recommend that you always use `-g' whenever you compile a program. You may think your program is correct, but there is no sense in pushing your luck. For more information, see 11. Debugging Optimized Code.
Older versions of the GNU C compiler permitted a variant option `-gg' for debugging information. GDB no longer supports this format; if your GNU C compiler has this option, do not use it.
GDB knows about preprocessor macros and can show you their expansion (see section 12. C Preprocessor Macros). Most compilers do not include information about preprocessor macros in the debugging information if you specify the `-g' flag alone. Version 3.1 and later of GCC, the GNU C compiler, provides macro information if you are using the DWARF debugging format, and specify the option `-g3'.
See section `Options for Debugging Your Program or GCC' in Using the GNU Compiler Collection (GCC), for more information on GCC options affecting debug information.
You will have the best debugging experience if you use the latest version of the DWARF debugging format that your compiler supports. DWARF is currently the most expressive and best supported debugging format in GDB.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
run
r
run command to start your program under GDB.
You must first specify the program name (except on VxWorks) with an
argument to GDB (see section Getting In and Out of GDB), or by using the file or exec-file command
(see section Commands to Specify Files).
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:
The "remote" target does not support "run". Try "help target" or "continue". |
then use continue to run your program. You may need load
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:
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 the
SHELL environment variable.
See section Your Program's Arguments.
set environment and unset
environment to change parts of the environment that affect
your program. See section Your Program's Environment.
cd command in GDB.
See section Your Program's Working Directory.
run command line, or you can use the tty command to
set a different device for your program.
See section 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 section 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 section 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.
start
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.
set exec-wrapper wrapper
show exec-wrapper
unset exec-wrapper
You can use any program that eventually calls execve with
its arguments as a wrapper. Several standard Unix utilities do
this, e.g. env and nohup. Any Unix shell script ending
with exec "$@" 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) run |
This command is available when debugging locally on most targets, excluding DJGPP, Cygwin, MS Windows, and QNX Neutrino.
set disable-randomization
set disable-randomization on
This feature is implemented only on certain targets, including GNU/Linux. On GNU/Linux you can get the same behavior using
(gdb) set exec-wrapper setarch `uname -m` -R |
set disable-randomization off
On targets where it is available, virtual address space randomization protects the programs against certain 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 disable-randomization
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
set args
set args has no arguments, run executes your program
with no arguments. Once you have run your program with arguments,
using set args before the next run is the only way to run
it again without arguments.
show args
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
path directory
PATH environment variable
(the search path for executables) that will be passed to your program.
The value of PATH 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.
show paths
PATH
environment variable).
show environment [varname]
environment as env.
set environment varname [=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.)
unset environment varname
unset environment removes the variable from the environment,
rather than assigning it an empty value.
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'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section Commands to Specify Files.
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 section 21.1.3 SVR4 Process Information) to find out the
current working directory of the debuggee.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
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 the tty command. This command accepts a file name as
argument, and causes this file to be the default for future run
commands. It also resets the controlling terminal for the child
process, for future run commands. For example,
tty /dev/ttyb |
directs that processes started with subsequent run commands
default to do input and output on the terminal `/dev/ttyb' and have
that as their controlling terminal.
An explicit redirection in run overrides the tty command's
effect on the input/output device, but not its effect on the controlling
terminal.
When you use the tty command or redirect input in the run
command, only the input for your program is affected. The input
for GDB still comes from your terminal. tty is an alias
for set inferior-tty.
You can use the show 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
show inferior-tty
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
attach process-id
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 the ps utility,
or with the `jobs -l' shell command.
attach does not repeat if you press RET a second time after
executing the command.
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 section Specifying Source Directories). You can also use
the file command to load the program. See section 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.
detach
detach command to release it from GDB control. Detaching
the process continues its execution. After the detach command,
that process and GDB become completely independent once more, and you
are ready to attach another process or start one with run.
detach does not repeat if you press RET again after
executing the command.
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 section Optional Warnings and Messages).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
GDB displays for each inferior (in this order):
An asterisk `*' preceding the GDB inferior 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 inferior command:
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-inferiors command.
add-inferior [ -copies n ] [ -exec executable ]
file command with the executable name as its argument.
clone-inferior [ -copies n ] [ infno ]
(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...
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...
info inferiors,
but its Description will show `<null>'.
kill inferiors infno...
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
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
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
GDB displays for each program space (in this order):
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 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 vfork call.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
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 thethreadcommand, like this:
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 0x41e02940 (LWP 25582)] |
when GDB notices a new thread. In contrast, on an SGI system, the systag is simply something like `process 368', with no further qualifier.
For debugging purposes, GDB associates its own thread number--always a single integer--with each thread in your program.
info threads [id...]
thread name, below), or, in some cases, by the
program itself.
An asterisk `*' to the left of the GDB thread number indicates the current thread.
For example,
(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:
maint info sol-threads
thread threadno
(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 section Convenience Variables, for general information on convenience variables.
thread apply [threadno | all] command
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 in 2-4. To apply a
command to all threads, type thread apply all command.
thread name [name]
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.
thread find [regexp]
As well as being the complement to the `thread name' command, this command also allows you to identify a thread by its target systag. For instance, on GNU/Linux, the target systag is the LWP id.
(GDB) thread find 26688 Thread 4 has target id 'Thread 0x41e02940 (LWP 26688)' (GDB) info thread 4 Id Target Id Frame 4 Thread 0x41e02940 (LWP 26688) 0x00000031ca6cd372 in select () |
set print thread-events
set print thread-events on
set print thread-events off
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 print thread-events
See section Stopping and Starting Multi-thread Programs, for more information about how GDB behaves when you stop and start programs with multiple threads.
See section Setting Watchpoints, for information about watchpoints in programs with multiple threads.
set libthread-db-search-path [path]
libthread_db.
If you omit path, `libthread-db-search-path' will be reset to
its default value ($sdir:$pdir on GNU/Linux and Solaris systems).
Internally, the default value comes from the LIBTHREAD_DB_SEARCH_PATH
macro.
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 find libthread_db.
A special entry `$sdir' for `libthread-db-search-path' refers to the default system directories that are normally searched for loading shared libraries.
A special entry `$pdir' for `libthread-db-search-path'
refers to the directory from which libpthread
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 between libthread_db and libpthread), GDB
will unload libthread_db, and continue with the next directory.
If none of libthread_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.
show libthread-db-search-path
set debug libthread-db
show debug libthread-db
libthread_db-related events.
Use 1 to enable, 0 to disable.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 4.7 Debugging an Already-running Process). 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 follow-fork-mode mode
fork or
vfork. A call to fork or vfork creates a new
process. The mode argument can be:
parent
child
show follow-fork-mode
fork or vfork call.
On Linux, if you want to debug both the parent and child processes, use the
command set detach-on-fork.
set detach-on-fork mode
on
follow-fork-mode) will be detached and allowed to run
independently. This is the default.
off
follow-fork-mode) is debugged as usual, while the other
is held suspended.
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 section Debugging Multiple Inferiors and Programs).
To quit debugging one of the forked processes, you can either detach
from it by using the detach inferiors command (allowing it
to run independently), or kill it using the kill inferiors
command. See section 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 follow-exec-mode mode
Set debugger response to a program call of exec. An
exec call replaces the program image of a process.
follow-exec-mode can be:
new
exec call can be restarted afterwards by restarting the
original inferior.
For example:
(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 1 <null> prog1 |
same
exec call, with
e.g., the run command, restarts the executable the process was
running after the exec 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 |
You can use the catch command to make GDB stop whenever
a fork, vfork, or exec call is made. See section Setting Catchpoints.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
On certain operating systems(3), 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:
checkpoint
checkpoint command takes no arguments, but each checkpoint
is assigned a small integer id, similar to a breakpoint id.
info checkpoints
Checkpoint ID
Process ID
Code Address
Source line, or label
restart checkpoint-id
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 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |