Debugging with GDB (September 2007)

104 Debugging with GDB
symbol-file does not repeat if you press
h
RET
i
again after executing it once.
When GDB is configured for a particular environment, it understands debug-
ging information in whatever format is the standard generated for that envi-
ronment; 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 w hich 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 17.6
[Optional warnings and messages], page 248.)
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-mapp e d 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 exe-
cutable 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 symb ol 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.