gdb.info: Files

Go forward to Separate Debug Files
Go up to GDB Files
Go to the top op gdb

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 (*note 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.  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.
     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'
     `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 ]'
     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 <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.  *Note 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 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-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.
`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 (*note Killing the child process: Kill Process.).
`add-symbol-file FILENAME ADDRESS'
`add-symbol-file FILENAME ADDRESS [ -readnow ] [ -mapped ]'
`add-symbol-file FILENAME -sSECTION 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.  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 <RET> after using
     it.
     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.
`add-shared-symbol-file'
     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.
`section'
     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'
`info target'
     `info files' and `info target' are synonymous; both print the
     current target (*note 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.
   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:
`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'.
`show auto-solib-add'
     Display the current autoloading mode.
   To explicitly load shared library symbols, use the `sharedlibrary'
command:
`info share'
`info sharedlibrary'
     Print the names of the shared libraries which are currently loaded.
`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.
   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 auto-solib-limit THRESHOLD'
     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 (i.e. 100 Mb).
`show auto-solib-limit'
     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.
`set solib-absolute-prefix PATH'
     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.
`show solib-absolute-prefix'
     Display the current 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 `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.
`show solib-search-path'
     Display the current shared library search path.