18.1 Commands to Specify Files
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 (see 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. Or you are debugging a remote target
gdbserver (see file). 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
runcommand. If you do not specify a directory and the file is not found in the gdb working directory, gdb uses the environment variable
PATHas 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
You can load unlinked object .o files into gdb using the
filecommand. You will not be able to “run” an object file, but you can disassemble functions and inspect variables. Also, if the underlying BFD functionality supports it, you could use gdb -write to patch object files using this technique. Note that gdb can neither interpret nor modify relocations in this case, so branches and some initialized variables will appear to go to the wrong place. But this feature is still handy from time to time.
filewith no argument makes gdb discard any information it has on both executable file and the symbol table.
exec-file[ filename ]
- Specify that the program to be run (but not the symbol table) is found
in filename. gdb searches the environment variable
PATHif necessary to locate your program. Omitting filename means to discard information on the executable file.
symbol-file[ filename ]
- Read symbol table information from file filename.
PATHis searched when necessary. Use the
filecommand to get both symbol table and program to run from the same file.
symbol-filewith no argument clears out gdb information on your program's symbol table.
symbol-filecommand causes gdb to forget the contents of some 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-filedoes not repeat if you press <RET> again after executing it once.
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-filecommand 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 verbosecommand can turn these pauses into messages if desired. See 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-filereads 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.
- 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-filewith 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
killcommand (see Killing the Child Process).
add-symbol-filefilename address [
add-symbol-filefilename -ssection address
add-symbol-filecommand 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-filecommand. You can use the
add-symbol-filecommand 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-filecommand 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
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 (
.linkoncesection factoring and C++ constructor table assembly, for example) that make the requirements difficult to meet. In general, one cannot assume that using
add-symbol-fileto 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-filedoes not repeat if you press <RET> after using it.
- Load symbols from the given address in a dynamically loaded
object file whose image is mapped directly into the inferior's memory.
For example, the Linux kernel maps a
syscall DSOinto each process's address space; this DSO provides kernel-specific code for some system calls. The argument can be any expression whose evaluation yields the address of the file's shared object file header. For this command to work, you must have used
exec-filecommands in advance.
add-shared-symbol-filescommand can currently be used only in the Cygwin build of gdb on MS-Windows OS, where it is an alias for the
dll-symbolscommand (see Cygwin Native). gdb automatically looks for shared libraries, however if gdb does not find yours, you can invoke
add-shared-symbol-files. It takes one argument: the shared library's file name.
assfis a shorthand alias for
sectioncommand changes the base address of the named 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.outformat), or when the addresses specified in the file itself are wrong. Each section must be changed separately. The
info filescommand, described below, lists all the sections and their addresses.
info targetare synonymous; both print the current target (see 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 targetlists all possible targets rather than current ones.
maint info sections
- Another command that can give you extra information about program sections
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 sectionsprovides 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
- 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.
set trust-readonly-sections on
- Tell gdb that readonly sections in your object file
really are read-only (i.e. 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.
set trust-readonly-sections 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.
- Show the current setting of trusting readonly sections.
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.
On MS-Windows gdb must be linked with the Expat library to support shared libraries. See Expat.
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
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.
- 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
sharedlibrarycommand. The default value is
If your program uses lots of shared libraries with debug info that takes large amounts of memory, you can decrease the gdb memory footprint by preventing it from automatically loading the symbols from shared libraries. To that end, type set auto-solib-add off before running the inferior, then load each library whose debug symbols you do need with sharedlibrary regexp, where regexp is a regular expression that matches the libraries whose symbols you want to be loaded.
- Display the current autoloading mode.
- Print the names of the shared libraries which are currently loaded that match regex. If regex is omitted then print all shared libraries that are 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.
- Unload all shared object library symbols. This discards all symbols that have been loaded from all shared libraries. Symbols from shared libraries that were loaded by explicit user requests are not discarded.
Sometimes you may wish that gdb stops and gives you control
when any of shared library events happen. Use the
stop-on-solib-events command for this:
- This command controls whether gdb should give you control
when the dynamic linker notifies it about some shared library event.
The most common event of interest is loading or unloading of a new
- Show whether gdb stops and gives you control when shared library events happen.
Shared libraries are also supported in many cross or remote debugging configurations. gdb needs to have access to the target's libraries; this can be accomplished either by providing copies of the libraries on the host system, or by asking gdb to automatically retrieve the libraries from the target. If copies of the target libraries are provided, 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.
For remote debugging, 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.
- Use path as the system root for the program being debugged. Any
absolute shared library paths will be prefixed with path; many
runtime loaders store the absolute paths to the shared library in the
target program's memory. If you use
set sysrootto find shared libraries, they need to be laid out in the same way that they are on the target, with e.g. a /lib and /usr/lib hierarchy under path.
If path starts with the sequence remote:, gdb will retrieve the target libraries from the remote system. This is only supported when using a remote target that supports the
remote getcommand (see Sending files to a remote system). The part of path following the initial remote: (if present) is used as system root prefix on the remote file system. 1
For targets with an MS-DOS based filesystem, such as MS-Windows and SymbianOS, gdb tries prefixing a few variants of the target absolute file name with path. But first, on Unix hosts, gdb converts all backslash directory separators into forward slashes, because the backslash is not a directory separator on Unix:
c:\foo\bar.dll => c:/foo/bar.dll
Then, gdb attempts prefixing the target file name with path, and looks for the resulting file name in the host file system:
c:/foo/bar.dll => /path/to/sysroot/c:/foo/bar.dll
If that does not find the shared library, gdb tries removing the : character from the drive spec, both for convenience, and, for the case of the host file system not supporting file names with colons:
c:/foo/bar.dll => /path/to/sysroot/c/foo/bar.dll
This makes it possible to have a system root that mirrors a target with more than one drive. E.g., you may want to setup your local copies of the target system shared libraries like so (note c vs z):
/path/to/sysroot/c/sys/bin/foo.dll /path/to/sysroot/c/sys/bin/bar.dll /path/to/sysroot/z/sys/bin/bar.dll
and point the system root at /path/to/sysroot, so that gdb can find the correct copies of both c:\sys\bin\foo.dll, and z:\sys\bin\bar.dll.
If that still does not find the shared library, gdb tries removing the whole drive spec from the target file name:
c:/foo/bar.dll => /path/to/sysroot/foo/bar.dll
This last lookup makes it possible to not care about the drive name, if you don't want or need to.
set solib-absolute-prefixcommand is an alias for
You can set the default system root by using the configure-time --with-sysroot option. If the system root is inside gdb's configured binary prefix (set with --prefix or --exec-prefix), then the default system root will be updated automatically if the installed gdb is moved to a new location.
- 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 sysroot 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 sysroot, be sure to set sysroot to a nonexistent directory to prevent gdb from finding your host's libraries. sysroot is preferred; setting it to a nonexistent directory may interfere with automatic loading of shared library symbols.
- Display the current shared library search path.
- Set assumed file system kind for target reported file names.
Shared library file names as reported by the target system may not make sense as is on the system gdb is running on. For example, when remote debugging a target that has MS-DOS based file system semantics, from a Unix host, the target may be reporting to gdb a list of loaded shared libraries with file names such as c:\Windows\kernel32.dll. On Unix hosts, there's no concept of drive letters, so the c:\ prefix is not normally understood as indicating an absolute file name, and neither is the backslash normally considered a directory separator character. In that case, the native file system would interpret this whole absolute file name as a relative file name with no directory components. This would make it impossible to point gdb at a copy of the remote target's shared libraries on the host using
set sysroot, and impractical with
set solib-search-path. Setting
dos-basedtells gdb to interpret such file names similarly to how the target would, and to map them to file names valid on gdb's native file system semantics. The value of kind can be
"auto", in addition to one of the supported file system kinds. In that case, gdb tries to determine the appropriate file system variant based on the current target's operating system (see Configuring the Current ABI). The supported file system settings are:
- Instruct gdb to assume the target file system is of Unix
kind. Only file names starting the forward slash (/) character
are considered absolute, and the directory separator character is also
the forward slash.
- Instruct gdb to assume the target file system is DOS based.
File names starting with either a forward slash, or a drive letter
followed by a colon (e.g., c:), are considered absolute, and
both the slash (/) and the backslash (\\) characters are
considered directory separators.
- Instruct gdb to use the file system kind associated with the target operating system (see Configuring the Current ABI). This is the default.
 If you want to specify a local system root using a directory that happens to be named remote:, you need to use some equivalent variant of the name like ./remote:.