Red Hat ENTERPRISE LINUX 3 - DEBUGGING WITH GDB Manual page 150

140
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 com-
piler, or other compilers that adhere to the local conventions. Best results are usually obtained
from gnu compilers; for example, using
mized code.
For most kinds of object files, with the exception of old SVR3 systems using COFF, the
command does not normally read the symbol table in full right away. Instead, it
symbol-file
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
Refer to Section 21.7 Optional warnings and messages.)
We have not implemented the two-stage strategy for COFF yet. When the symbol table is stored
in COFF format,
in-COFF" still does the two-stage strategy, since the debug info is actually in stabs format.
symbol-file
filename
file [ -readnow ] [ -mapped ]
filename
You can override the gdb two-stage strategy for reading symbol tables by using the
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
another option,
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
command-line option.
-mapped
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
exists (so long as it is newer than the corresponding executable), gdb always attempts to use it
when you debug
The file is specific to the host machine where you run gdb. It holds an exact image of the
.syms
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". Tradition-
ally, 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.
with no argument specifies that no core file is to be used.
core-file
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
6.8 Killing the child process).
set verbose
reads the symbol table data in full right away. Note that "stabs-
symbol-file
[ -readnow ] [ -mapped ]
, to cause gdb to write the symbols for your program into a reusable
-mapped
-mapped
; no special options or commands are needed.
myprog
]
you can generate debugging information for opti-
gcc
command can turn these pauses into messages if desired.
option has the same effect as starting gdb with the
is called
myprog
Chapter 17. gdb Files
system call, you can use
mmap
. Once this file
.syms
myprog
command (refer to Section
kill
-readnow