Contents|Index|Previous|Next
Commands
to specify 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. In these situations the GDB
commands to specify new files are useful.
file
filename
Use filename
as the program to be debugged. It is read for its symbols and for the contents
of pure memory. It is also the program executed when you use the run
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.
On systems with memory-mapped
files, an auxiliary file, filename.syms,
may hold symbol table information for filename.
If so, GDB maps in the symbol table from ‘filename.syms’,
starting up more quickly. See the descriptions of the file options, -mapped
and -readnow
(available on the command line, and with the commands, file,
symbol-file,
or add-symbol-file,
described in the following), for more information.
file
file
with no argument makes GDB discard any information it has on both executable
file and the symbol table.
exec-file [filename]
Specify that the program
to be run (but not the symbol table) is found in filename.
GDB searches the environment variable, PATH,
if necessary to locate your program. Omitting filename
means to discard information on the executable file.
symbol-file [filename]
Read symbol table information
from 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 its convenience variables,
the value history, and all 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 use Return
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.
On some kinds of object
files, 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.
symbol-file filename[-readnow][-mapped]
file filename[-readnow][-mapped]
You can override the GDB
two-stage strategy for reading symbol tables by using the ‘-readnow’
option with any of the commands that load symbol table information, if
you want to be sure GDB has the entire symbol table available.
If memory-mapped files are
available on your system through the mmap system call, you can use another
option, ‘-mapped’,
to cause GDB to write the symbols for your program into a reusable file.
Future GDB debugging sessions map in symbol information from this auxiliary
symbol file (if the program has not changed), rather than spending time
reading the symbol table from the executable program.
Using the ‘-mapped’
option has the same effect as starting GDB with the ‘-mapped’
command-line option.
You can use both options
together, to make sure the auxiliary symbol file has all the symbol information
for your program. The auxiliary symbol file for a program called myprog
is called ‘myprog.syms’.
Once this file exists (so long as it is newer than the corresponding executable),
GDB always attempts to use it when you debug myprog;
no special options or commands are needed.
The ‘.syms’
file is specific to the host machine where you run GDB. It holds an exact
image of the internal GDB symbol table. It cannot be shared across multiple
host platforms.
core-file [filename]
Specify the whereabouts
of a core dump file to be used as the “contents of memory”. Traditionally,
core files contain only some parts of the address space of the process
that generated them; GDB can access the executable file itself for other
parts.
core-file
with no argument specifies that no core file is to be used.
Note:
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).
load
filename
Depending on what remote
debugging facilities are configured into GDB, the load
command may be available. Where it exists, it is meant to make filename
(an executable)
available for debugging on the remote system—by downloading, or dynamic
linking, for example. load
also records the filename
symbol table in GDB, like the add-symbol-file
command.
If your GDB does not have
a load
command, attempting to execute it gets the error message, You
can’t
do that when your target is
....
The file is loaded at whatever
address is specified in the executable. For some object file formats, you
can specify the load address when you link the program; for other formats,
like a.out, the object file format specifies a fixed address.
On VxWorks, load
links filename
dynamically on the current target system as well as adding its symbols
in GDB.
With the Nindy interface
to an Intel 960 board, load
downloads filename
to the 960 as well as adding its symbols in GDB.
When you select remote debugging
to a Hitachi SH, H8/300, or H8/500 board (see GDB
and Hitachi Microprocessors), the load
command downloads your program to the Hitachi board and also opens it as
the current executable target for GDB on your host (like the file
command).
load
does not repeat if you use Return
again after using it.
add-symbol-file
filename address
add-symbol-file
filename address[-readnow][-mapped]
The 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 specify 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 command, add-symbol-file,
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.
add-symbol-file
does not repeat if, after using it, you use Return.
You can use the ‘-mapped’
and ‘-readnow’
options, just as with the symbol-file
command, to change how GDB manages the symbol table information for filename.
add-shared-symbol-file
The add-shared-symbol-file
command can be used only under Harris’ CXUX operating system for the Motorola
88k. GDB automatically looks for shared libraries, however if GDB does
not find yours, you can run add-shared-symbol-file.
It takes no arguments.
section
The section
command changes the base address of section, 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
lists all the sections and their addresses.
info files
info target
info 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 help
target command
lists all possible targets rather than current ones.
All 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 SunOS, SVr4,
Irix 5, and IBM RS/6000 shared libraries. 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, remember that GDB does not understand references to a function
in a shared library, unless you are debugging a core file).
info share
info sharedlibrary
Print the names of the shared
libraries which are currently loaded.
sharedlibrary
regex
share
regex
Load shared object library
symbols for files matching a Unix regular expression. As with files loaded
automatically, it only loads shared libraries required by your program
for a core file or after using run.
If regex
is omitted, all shared libraries required by your program are loaded.
Top|Contents|Index|Previous|Next