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.
You may want to specify executable and core dump file names. The usual way to do this is at start-up time, using the arguments to gdb's start-up commands (refer to Chapter 4 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.
Use filename as the program to be debugged. It is read for its symbols and for the contents of pure memory. It is also the program executed when you use the 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 named 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 file options -mapped and -readnow (available on the command line, and with the commands file, symbol-file, or add-symbol-file, described below), for more information.
file with no argument makes gdb discard any information it has on both executable file and the symbol table.
Specify that the program to be run (but not the symbol table) is found in filename. gdb searches the environment variable PATH if necessary to locate your program. Omitting filename means to discard information on the executable file.
Read symbol table information from 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
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.
For most kinds of object files, with the exception of old SVR3 systems using COFF, 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. 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, symbol-file reads the symbol table data in full right away. Note that "stabs-in-COFF" still does the two-stage strategy, since the debug info is actually in stabs format.
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-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.
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 (refer to Section 6.8 Killing the child process).
The 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 additionally specify an arbitrary number of -ssection address pairs, to give an explicit section name and base address for that section. You can specify any 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 without any arguments.
Although filename is typically a shared library file, an executable file, or some other object file which has been fully relocated for loading into a process, you can also load symbolic information from relocatable .o files, as long as:
the file's symbolic information refers only to linker symbols defined in that file, not to symbols defined by other object files,
every section the file's symbolic information refers to has actually been loaded into the inferior, as it appears in the file, and
you can determine the address at which every section was loaded, and provide these to the add-symbol-file command.
Some embedded operating systems, like Sun Chorus and VxWorks, can load relocatable files into an already running program; such systems typically make the requirements above easy to meet. However, it's important to recognize that many native systems use complex link procedures (.linkonce section factoring and C++ constructor table assembly, for example) that make the requirements difficult to meet. In general, one cannot assume that using add-symbol-file to read a relocatable object file's symbolic information will have the same effect as linking the relocatable object file into the program in the normal way.
add-symbol-file does not repeat if you press
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.
The add-shared-symbol-file command can be used only under Harris' CXUX operating system for the Motorola 88k. gdb automatically looks for shared libraries, however if gdb does not find yours, you can run add-shared-symbol-file. It takes no arguments.
The section command changes the base address of section SECTION of the exec file to ADDR. This can be used if the exec file does not contain section addresses, (such as in the a.out format), or when the addresses specified in the file itself are wrong. Each section must be changed separately. The info files command, described below, lists all the sections and their addresses.
info files and info target are synonymous; both print the current target (refer to Chapter 18 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.
Another command that can give you extra information about program sections is maint info sections. In addition to the section information displayed by info files, this command displays the flags and file offset of each section in the executable and core dump files. In addition, maint info sections provides the following command options (which may be arbitrarily combined):
Display sections for all loaded object files, including shared libraries.
Display info only for named sections.
Display info only for sections for which section-flags are true. The section flags that gdb currently knows about are:
Section will have space allocated in the process when loaded. Set for all sections except those containing debug information.
Section will be loaded from the file into the child process memory. Set for pre-initialized code and data, clear for .bss sections.
Section needs to be relocated before loading.
Section cannot be modified by the child process.
Section contains executable code only.
Section contains data only (no executable code).
Section will reside in ROM.
Section contains data for constructor/destructor lists.
Section is not empty.
An instruction to the linker to not output the section.
A notification to the linker that the section contains COFF shared library information.
Section contains common symbols.
Tell gdb that readonly sections in your object file really are read-only (that is, that their contents will not change). In that case, gdb can fetch values from these sections out of the object file, rather than from the target program. For some targets (notably embedded ones), this can be a significant enhancement to debugging performance.
The default is off.
Tell gdb not to trust readonly sections. This means that the contents of the section might change while the program is running, and must therefore be fetched from the target when needed.
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 HP-UX, 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).
On HP-UX, if the program loads a library explicitly, gdb automatically loads the symbols at the time of the shl_load call.
There are times, however, when you may wish to not automatically load symbol definitions from shared libraries, such as when they are particularly large or there are many of them.
To control the automatic loading of shared library symbols, use the commands:
If mode is on, symbols from all shared object libraries will be loaded automatically when the inferior begins execution, you attach to an independently started inferior, or when the dynamic linker informs gdb that a new library has been loaded. If mode is off, symbols must be loaded manually, using the sharedlibrary command. The default value is on.
Display the current autoloading mode.
To explicitly load shared library symbols, use the sharedlibrary command:
Print the names of the shared libraries which are currently loaded.
Load shared object library symbols for files matching a Unix regular expression. As with files loaded automatically, it only loads shared libraries required by your program for a core file or after typing run. If regex is omitted all shared libraries required by your program are loaded.
On some systems, such as HP-UX systems, gdb supports autoloading shared library symbols until a limiting threshold size is reached. This provides the benefit of allowing autoloading to remain on by default, but avoids autoloading excessively large shared libraries, up to a threshold that is initially set, but which you can modify if you wish.
Beyond that threshold, symbols from shared libraries must be explicitly loaded. To load these symbols, use the command sharedlibrary filename. The base address of the shared library is determined automatically by gdb and need not be specified.
To display or set the threshold, use the commands:
Set the autoloading size threshold, in an integral number of megabytes. If threshold is nonzero and shared library autoloading is enabled, symbols from all shared object libraries will be loaded until the total size of the loaded shared library symbols exceeds this threshold. Otherwise, symbols must be loaded manually, using the sharedlibrary command. The default threshold is 100 (that is, 100 Mb).
Display the current autoloading size threshold, in megabytes.
Shared libraries are also supported in many cross or remote debugging configurations. A copy of the target's libraries need to be present on the host system; they need to be the same as the target libraries, although the copies on the target can be stripped as long as the copies on the host are not.
You need to tell gdb where the target libraries are, so that it can load the correct copies--otherwise, it may try to load the host's libraries. gdb has two variables to specify the search directories for target libraries.
If this variable is set, path will be used as a prefix for any absolute shared library paths; many runtime loaders store the absolute paths to the shared library in the target program's memory. If you use solib-absolute-prefix to find shared libraries, they need to be laid out in the same way that they are on the target, with e.g. a /usr/lib hierarchy under path.
You can set the default value of solib-absolute-prefix by using the configure-time -with-sysroot option.
Display the current shared library prefix.
If this variable is set, path is a colon-separated list of directories to search for shared libraries. solib-search-path is used after solib-absolute-prefix fails to locate the library, or if the path to the library is relative instead of absolute. If you want to use solib-search-path instead of solib-absolute-prefix, be sure to set solib-absolute-prefix to a nonexistant directory to prevent gdb from finding your host's libraries.
Display the current shared library search path.