Next: Separate Debug Files, Up: GDB Files
You may want to specify executable and core dump file names. The usual way to do this is at start-up time, using the arguments to gdb's start-up commands (see Getting In and Out of gdb).
Occasionally it is necessary to change to a different file during a
gdb session. Or you may run gdb and forget to
specify a file you want to use. Or you are debugging a remote target
via gdbserver (see file). In these situations the gdb commands to specify
new files are useful.
file filenamerun command. If you do not specify a
directory and the file is not found in the gdb working directory,
gdb uses the environment variable PATH as a list of
directories to search, just as the shell does when looking for a program
to run. You can change the value of this variable, for both gdb
and your program, using the path command.
You can load unlinked object .o files into gdb using
the file command. You will not be able to “run” an object
file, but you can disassemble functions and inspect variables. Also,
if the underlying BFD functionality supports it, you could use
gdb -write to patch object files using this technique. Note
that gdb can neither interpret nor modify relocations in this
case, so branches and some initialized variables will appear to go to
the wrong place. But this feature is still handy from time to time.
filefile with no argument makes gdb discard any information it
has on both executable file and the symbol table.
exec-file [ filename ]PATH
if necessary to locate your program. Omitting filename means to
discard information on the executable file.
symbol-file [ filename ]PATH is
searched when necessary. Use the file command to get both symbol
table and program to run from the same file.
symbol-file with no argument clears out gdb information on your
program's symbol table.
The symbol-file command causes gdb to forget the contents of
some breakpoints and auto-display expressions. This is because they may
contain pointers to the internal data recording symbols and data types,
which are part of the old symbol table data being discarded inside
gdb.
symbol-file does not repeat if you press <RET> again after
executing it once.
When gdb is configured for a particular environment, it understands debugging information in whatever format is the standard generated for that environment; you may use either a gnu compiler, or other compilers that adhere to the local conventions. Best results are usually obtained from gnu compilers; for example, using gcc you can generate debugging information for optimized code.
For most kinds of object files, with the exception of old SVR3 systems
using COFF, the symbol-file command does not normally read the
symbol table in full right away. Instead, it scans the symbol table
quickly to find which source files and which symbols are present. The
details are read later, one source file at a time, as they are needed.
The purpose of this two-stage reading strategy is to make gdb
start up faster. For the most part, it is invisible except for
occasional pauses while the symbol table details for a particular source
file are being read. (The set verbose command can turn these
pauses into messages if desired. See Optional Warnings and Messages.)
We have not implemented the two-stage strategy for COFF yet. When the
symbol table is stored in COFF format, symbol-file reads the
symbol table data in full right away. Note that “stabs-in-COFF”
still does the two-stage strategy, since the debug info is actually
in stabs format.
symbol-file filename [ -readnow ]file filename [ -readnow ]core-file [filename]corecore-file with no argument specifies that no core file is
to be used.
Note that the core file is ignored when your program is actually running
under gdb. So, if you have been running your program and you
wish to debug a core file instead, you must kill the subprocess in which
the program is running. To do this, use the kill command
(see Killing the Child Process).
add-symbol-file filename addressadd-symbol-file filename address [ -readnow ]add-symbol-file filename -ssection address ...add-symbol-file command reads additional symbol table
information from the file filename. You would use this command
when filename has been dynamically loaded (by some other means)
into the program that is running. address should be the memory
address at which the file has been loaded; gdb cannot figure
this out for itself. You can additionally specify an arbitrary number
of `-ssection address' pairs, to give an explicit
section name and base address for that section. You can specify any
address as an expression.
The symbol table of the file filename is added to the symbol table
originally read with the symbol-file command. You can use the
add-symbol-file command any number of times; the new symbol data
thus read keeps adding to the old. To discard all old symbol data
instead, use the symbol-file command without any arguments.
Although filename is typically a shared library file, an executable file, or some other object file which has been fully relocated for loading into a process, you can also load symbolic information from relocatable .o files, as long as:
add-symbol-file command.
Some embedded operating systems, like Sun Chorus and VxWorks, can load
relocatable files into an already running program; such systems
typically make the requirements above easy to meet. However, it's
important to recognize that many native systems use complex link
procedures (.linkonce section factoring and C++ constructor table
assembly, for example) that make the requirements difficult to meet. In
general, one cannot assume that using add-symbol-file to read a
relocatable object file's symbolic information will have the same effect
as linking the relocatable object file into the program in the normal
way.
add-symbol-file does not repeat if you press <RET> after using it.
add-symbol-file-from-memory addresssyscall DSO into each
process's address space; this DSO provides kernel-specific code for
some system calls. The argument can be any expression whose
evaluation yields the address of the file's shared object file header.
For this command to work, you must have used symbol-file or
exec-file commands in advance.
add-shared-symbol-files library-fileassf library-fileadd-shared-symbol-files command can currently be used only
in the Cygwin build of gdb on MS-Windows OS, where it is an
alias for the dll-symbols command (see Cygwin Native).
gdb automatically looks for shared libraries, however if
gdb does not find yours, you can invoke
add-shared-symbol-files. It takes one argument: the shared
library's file name. assf is a shorthand alias for
add-shared-symbol-files.
section section addrsection command changes the base address of the named
section of the exec file to addr. This can be used if the
exec file does not contain section addresses, (such as in the
a.out format), or when the addresses specified in the file
itself are wrong. Each section must be changed separately. The
info files command, described below, lists all the sections and
their addresses.
info filesinfo targetinfo files and info target are synonymous; both print the
current target (see Specifying a Debugging Target),
including the names of the executable and core dump files currently in
use by gdb, and the files from which symbols were loaded. The
command help target lists all possible targets rather than
current ones.
maint info sectionsmaint info sections. In addition to the section information
displayed by info files, this command displays the flags and file
offset of each section in the executable and core dump files. In addition,
maint info sections provides the following command options (which
may be arbitrarily combined):
ALLOBJALLOCLOAD.bss sections.
RELOCREADONLYCODEDATAROMCONSTRUCTORHAS_CONTENTSNEVER_LOADCOFF_SHARED_LIBRARYIS_COMMONset trust-readonly-sections onThe default is off.
set trust-readonly-sections offshow trust-readonly-sectionsAll file-specifying commands allow both absolute and relative file names as arguments. gdb always converts the file name to an absolute file name and remembers it that way.
gdb supports gnu/Linux, MS-Windows, HP-UX, SunOS, SVr4, Irix, and IBM RS/6000 AIX shared libraries.
On MS-Windows gdb must be linked with the Expat library to support shared libraries. See Expat.
gdb automatically loads symbol definitions from shared libraries
when you use the run command, or when you examine a core file.
(Before you issue the run command, gdb does not understand
references to a function in a shared library, however—unless you are
debugging a core file).
On HP-UX, if the program loads a library explicitly, gdb
automatically loads the symbols at the time of the shl_load call.
There are times, however, when you may wish to not automatically load symbol definitions from shared libraries, such as when they are particularly large or there are many of them.
To control the automatic loading of shared library symbols, use the commands:
set auto-solib-add modeon, symbols from all shared object libraries
will be loaded automatically when the inferior begins execution, you
attach to an independently started inferior, or when the dynamic linker
informs gdb that a new library has been loaded. If mode
is off, symbols must be loaded manually, using the
sharedlibrary command. The default value is on.
If your program uses lots of shared libraries with debug info that takes large amounts of memory, you can decrease the gdb memory footprint by preventing it from automatically loading the symbols from shared libraries. To that end, type set auto-solib-add off before running the inferior, then load each library whose debug symbols you do need with sharedlibrary regexp, where regexp is a regular expression that matches the libraries whose symbols you want to be loaded.
show auto-solib-addTo explicitly load shared library symbols, use the sharedlibrary
command:
info shareinfo sharedlibrarysharedlibrary regexshare regexrun. If
regex is omitted all shared libraries required by your program are
loaded.
nosharedlibrarySometimes you may wish that gdb stops and gives you control
when any of shared library events happen. Use the set
stop-on-solib-events command for this:
set stop-on-solib-eventsshow stop-on-solib-eventsShared libraries are also supported in many cross or remote debugging configurations. A copy of the target's libraries need to be present on the host system; they need to be the same as the target libraries, although the copies on the target can be stripped as long as the copies on the host are not.
For remote debugging, you need to tell gdb where the target libraries are, so that it can load the correct copies—otherwise, it may try to load the host's libraries. gdb has two variables to specify the search directories for target libraries.
set sysroot pathset sysroot to find shared
libraries, they need to be laid out in the same way that they are on
the target, with e.g. a /lib and /usr/lib hierarchy
under path.
The set solib-absolute-prefix command is an alias for set
sysroot.
You can set the default system root by using the configure-time `--with-sysroot' option. If the system root is inside gdb's configured binary prefix (set with `--prefix' or `--exec-prefix'), then the default system root will be updated automatically if the installed gdb is moved to a new location.
show sysrootset solib-search-path pathshow solib-search-path