gdb: Files
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 (
Getting In and Out of GDB Invocation.).
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 via 'gdbserver' (
file Server.). In these situations the GDB commands to specify new
files are useful.
'file FILENAME'
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.
You can load unlinked object '.o' files into GDB using the 'file'
command. 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.
'file'
'file' with 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 'PATH' if
necessary to locate your program. Omitting FILENAME means to
discard information on the executable file.
'symbol-file [ FILENAME [ -o OFFSET ]]'
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.
If an optional OFFSET is specified, it is added to the start
address of each section in the symbol file. This is useful if the
program is relocated at runtime, such as the Linux kernel with
kASLR enabled.
'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 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-file' does 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-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. Optional Warnings and
Messages Messages/Warnings.)
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.
'symbol-file [ -readnow ] FILENAME'
'file [ -readnow ] FILENAME'
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.
'symbol-file [ -readnever ] FILENAME'
'file [ -readnever ] FILENAME'
You can instruct GDB to never read the symbolic information
contained in FILENAME by using the '-readnever' option.
--readnever.
'core-file [FILENAME]'
'core'
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 (Killing the Child Process Kill Process.).
'add-symbol-file FILENAME [ -readnow | -readnever ] [ -o OFFSET ] [ TEXTADDRESS ] [ -s SECTION ADDRESS ... ]'
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. The TEXTADDRESS parameter gives
the memory address at which the file's text section has been
loaded. You can additionally specify the base address of other
sections using an arbitrary number of '-s SECTION ADDRESS' pairs.
If a section is omitted, GDB will use its default addresses as
found in FILENAME. Any ADDRESS or TEXTADDRESS can be given as an
expression.
If an optional OFFSET is specified, it is added to the start
address of each section, except those for which the address was
specified explicitly.
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 is kept in addition to the old.
Changes can be reverted using the command 'remove-symbol-file'.
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 <RET> after using
it.
'remove-symbol-file FILENAME'
'remove-symbol-file -a ADDRESS'
Remove a symbol file added via the 'add-symbol-file' command. The
file to remove can be identified by its FILENAME or by an ADDRESS
that lies within the boundaries of this symbol file in memory.
Example:
(gdb) add-symbol-file /home/user/gdb/mylib.so 0x7ffff7ff9480
add symbol table from file "/home/user/gdb/mylib.so" at
.text_addr = 0x7ffff7ff9480
(y or n) y
Reading symbols from /home/user/gdb/mylib.so...done.
(gdb) remove-symbol-file -a 0x7ffff7ff9480
Remove symbol table from file "/home/user/gdb/mylib.so"? (y or n) y
(gdb)
'remove-symbol-file' does not repeat if you press <RET> after using
it.
'add-symbol-file-from-memory ADDRESS'
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 DSO' into 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 'symbol-file'
or 'exec-file' commands in advance.
'section SECTION ADDR'
The 'section' command 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.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'
'info target'
'info files' and 'info target' are synonymous; both print the
current target (Specifying a Debugging Target Targets.),
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.
'maint info sections'
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):
'ALLOBJ'
Display sections for all loaded object files, including shared
libraries.
'SECTIONS'
Display info only for named SECTIONS.
'SECTION-FLAGS'
Display info only for sections for which SECTION-FLAGS are
true. The section flags that GDB currently knows about are:
'ALLOC'
Section will have space allocated in the process when
loaded. Set for all sections except those containing
debug information.
'LOAD'
Section will be loaded from the file into the child
process memory. Set for pre-initialized code and data,
clear for '.bss' sections.
'RELOC'
Section needs to be relocated before loading.
'READONLY'
Section cannot be modified by the child process.
'CODE'
Section contains executable code only.
'DATA'
Section contains data only (no executable code).
'ROM'
Section will reside in ROM.
'CONSTRUCTOR'
Section contains data for constructor/destructor lists.
'HAS_CONTENTS'
Section is not empty.
'NEVER_LOAD'
An instruction to the linker to not output the section.
'COFF_SHARED_LIBRARY'
A notification to the linker that the section contains
COFF shared library information.
'IS_COMMON'
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 trust-readonly-sections'
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.
GDB supports GNU/Linux, MS-Windows, SunOS, Darwin/Mach-O, SVr4, IBM
RS/6000 AIX, QNX Neutrino, FDPIC (FR-V), and DSBT (TIC6X) shared
libraries.
On MS-Windows GDB must be linked with the Expat library to support
shared libraries. 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).
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:
'set auto-solib-add MODE'
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'.
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.
'show auto-solib-add'
Display the current autoloading mode.
To explicitly load shared library symbols, use the 'sharedlibrary'
command:
'info share REGEX'
'info sharedlibrary REGEX'
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.
'info dll REGEX'
This is an alias of 'info sharedlibrary'.
'sharedlibrary REGEX'
'share REGEX'
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.
'nosharedlibrary'
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. The best way to do this is to use
'catch load' and 'catch unload' (Set Catchpoints).
GDB also supports the the 'set stop-on-solib-events' command for
this. This command exists for historical reasons. It is less useful
than setting a catchpoint, because it does not allow for conditions or
commands as a catchpoint does.
'set stop-on-solib-events'
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
shared library.
'show stop-on-solib-events'
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.
'set sysroot PATH'
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. When starting processes remotely, and
when attaching to already-running processes (local or remote),
their executable filenames will be prefixed with PATH if reported
to GDB as absolute by the operating system. If you use 'set
sysroot' to find executables and shared libraries, they need to be
laid out in the same way that they are on the target, with e.g. a
'/bin', '/lib' and '/usr/lib' hierarchy under PATH.
If PATH starts with the sequence 'target:' and the target system is
remote then GDB will retrieve the target binaries from the remote
system. This is only supported when using a remote target that
supports the 'remote get' command (Sending files to a remote
system File Transfer.). The part of PATH following the initial
'target:' (if present) is used as system root prefix on the remote
file system. If PATH starts with the sequence 'remote:' this is
converted to the sequence 'target:' by 'set sysroot'(1). If you
want to specify a local system root using a directory that happens
to be named 'target:' or 'remote:', you need to use some equivalent
variant of the name like './target:'.
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 binary, 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 binary, 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.
The 'set solib-absolute-prefix' command is an alias for 'set
sysroot'.
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.
'show sysroot'
Display the current executable and shared library prefix.
'set solib-search-path PATH'
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.
'show solib-search-path'
Display the current shared library search path.
'set target-file-system-kind KIND'
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
'target-file-system-kind' to 'dos-based' tells 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 (Configuring the Current ABI ABI.). The
supported file system settings are:
'unix'
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.
'dos-based'
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.
'auto'
Instruct GDB to use the file system kind associated with the
target operating system (Configuring the Current ABI
ABI.). This is the default.
When processing file names provided by the user, GDB frequently needs
to compare them to the file names recorded in the program's debug info.
Normally, GDB compares just the "base names" of the files as strings,
which is reasonably fast even for very large programs. (The base name
of a file is the last portion of its name, after stripping all the
leading directories.) This shortcut in comparison is based upon the
assumption that files cannot have more than one base name. This is
usually true, but references to files that use symlinks or similar
filesystem facilities violate that assumption. If your program records
files using such facilities, or if you provide file names to GDB using
symlinks etc., you can set 'basenames-may-differ' to 'true' to instruct
GDB to completely canonicalize each pair of file names it needs to
compare. This will make file-name comparisons accurate, but at a price
of a significant slowdown.
'set basenames-may-differ'
Set whether a source file may have multiple base names.
'show basenames-may-differ'
Show whether a source file may have multiple base names.
---------- Footnotes ----------
(1) Historically the functionality to retrieve binaries from the
remote system was provided by prefixing PATH with 'remote:'
Info Catalog
gdb: GDB Files
gdb: File Caching