Go to the previous, next section.
GDB needs to know the file name of the program to be debugged, both in order to read its symbol table and in order to start your program. To debug a core dump of a previous run, you must also tell GDB the name of the core dump file.
The usual way to specify executable and core dump file names is with the command arguments given when you start GDB (see section 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
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 options `-mapped' and `-readnow'
(available on the command line, and with the commands file
,
symbol-file
, or add-symbol-file
), 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 ]
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 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 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.
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 section 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 ]
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 ]
core-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 section Killing the child process).
load filename
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 section 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 press RET again after using it.
add-symbol-file filename address
add-symbol-file filename address [ -readnow ] [ -mapped ]
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
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.
add-symbol-file
does not repeat if you press RET after using it.
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.
info files
info target
info files
and info target
are synonymous; both print
the current target (see section 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.
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, GDB does not understand
references to a function in a shared library, however--unless you are
debugging a core file).
info share
info sharedlibrary
sharedlibrary regex
share regex
run
. If
regex is omitted all shared libraries required by your program are
loaded.
While reading a symbol file, GDB occasionally encounters problems,
such as symbol types it does not recognize, or known bugs in compiler
output. By default, GDB does not notify you of such problems, since
they are relatively common and primarily of interest to people
debugging compilers. If you are interested in seeing information
about ill-constructed symbol tables, you can either ask GDB to print
only one message about each such type of problem, no matter how many
times the problem occurs; or you can ask GDB to print more messages,
to see how many times the problems occur, with the set
complaints
command (see section Optional warnings and messages).
The messages currently printed, and their meanings, include:
inner block not inside outer block in symbol
The symbol information shows where symbol scopes begin and end (such as at the start of a function or a block of statements). This error indicates that an inner scope block is not fully contained in its outer scope blocks.
GDB circumvents the problem by treating the inner block as if it had
the same scope as the outer block. In the error message, symbol
may be shown as "(don't know)
" if the outer block is not a
function.
block at address out of order
The symbol information for symbol scope blocks should occur in order of increasing addresses. This error indicates that it does not do so.
GDB does not circumvent this problem, and has trouble
locating symbols in the source file whose symbols it is reading. (You
can often determine what source file is affected by specifying
set verbose on
. See section Optional warnings and messages.)
bad block start address patched
The symbol information for a symbol scope block has a start address smaller than the address of the preceding source line. This is known to occur in the SunOS 4.1.1 (and earlier) C compiler.
GDB circumvents the problem by treating the symbol scope block as starting on the previous source line.
bad string table offset in symbol n
Symbol number n contains a pointer into the string table which is larger than the size of the string table.
GDB circumvents the problem by considering the symbol to have the
name foo
, which may cause other problems if many symbols end up
with this name.
unknown symbol type 0xnn
The symbol information contains new data types that GDB does not yet
know how to read. 0xnn
is the symbol type of the misunderstood
information, in hexadecimal.
GDB circumvents the error by ignoring this symbol information. This
usually allows you to debug your program, though certain symbols
are not accessible. If you encounter such a problem and feel like
debugging it, you can debug gdb
with itself, breakpoint on
complain
, then go up to the function read_dbx_symtab
and
examine *bufp
to see the symbol.
stub type has NULL name
const/volatile indicator missing (ok if using g++ v1.x), got...
The symbol information for a C++ member function is missing some information that recent versions of the compiler should have output for it.
info mismatch between compiler and debugger
GDB could not parse a type specification output by the compiler.
Go to the previous, next section.