Debugging with GDB Manual (5900-1473; WDB 6.2; January 2011)

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 40)).
add-symbol-file filename
address, add-symbol-file
The add-symbol-file command reads additional
symbol table information from the file filename.
You would use this command when filename has
filename address [ -readnow ]
been dynamically loaded (by some other means)
[ -mapped ], add-symbol-file
120 GDB Files