Debugging with GDB Manual HP WDB v6.3 (5900-2180, August 2012)

environment; you may use either a gnu compiler, or other
compilers that adhere to the local conventions.
For most 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” (page 227).)
symbol-file filename [
-readnow ] [ -mapped ], file
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.
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 ] 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 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” (page 35)).
96 GDB Files