671 lines
28 KiB
HTML
671 lines
28 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on November, 11 2002 by texi2html 1.64 -->
|
|
<!--
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
Karl Berry <karl@freefriends.org>
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
and many others.
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
|
|
|
-->
|
|
<HEAD>
|
|
<TITLE>Debugging with GDB: GDB Files</TITLE>
|
|
|
|
<META NAME="description" CONTENT="Debugging with GDB: GDB Files">
|
|
<META NAME="keywords" CONTENT="Debugging with GDB: GDB Files">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
|
|
|
</HEAD>
|
|
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
|
|
|
<A NAME="SEC127"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_15.html#SEC126"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_16.html#SEC128"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_3.html#SEC6"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_17.html#SEC130"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_35.html#SEC643">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H1> 15. GDB Files </H1>
|
|
<!--docid::SEC127::-->
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gdb_16.html#SEC128">15.1 Commands to specify files</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gdb_16.html#SEC129">15.2 Errors reading symbol files</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Files"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC128"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_16.html#SEC127"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_16.html#SEC129"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_16.html#SEC127"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_16.html#SEC127"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_17.html#SEC130"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_35.html#SEC643">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.1 Commands to specify files </H2>
|
|
<!--docid::SEC128::-->
|
|
<P>
|
|
|
|
<A NAME="IDX556"></A>
|
|
<A NAME="IDX557"></A>
|
|
</P><P>
|
|
|
|
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 section <A HREF="gdb_3.html#SEC6">Getting In and Out of GDB</A>).
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX558"></A>
|
|
<A NAME="IDX559"></A>
|
|
<DT><CODE>file <VAR>filename</VAR></CODE>
|
|
<DD>Use <VAR>filename</VAR> 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 <CODE>run</CODE> command. If you do not specify a
|
|
directory and the file is not found in the GDB working directory,
|
|
GDB uses the environment variable <CODE>PATH</CODE> 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 <CODE>path</CODE> command.
|
|
<P>
|
|
|
|
On systems with memory-mapped files, an auxiliary file named
|
|
<TT>`<VAR>filename</VAR>.syms'</TT> may hold symbol table information for
|
|
<VAR>filename</VAR>. If so, GDB maps in the symbol table from
|
|
<TT>`<VAR>filename</VAR>.syms'</TT>, starting up more quickly. See the
|
|
descriptions of the file options <SAMP>`-mapped'</SAMP> and <SAMP>`-readnow'</SAMP>
|
|
(available on the command line, and with the commands <CODE>file</CODE>,
|
|
<CODE>symbol-file</CODE>, or <CODE>add-symbol-file</CODE>, described below),
|
|
for more information.
|
|
</P><P>
|
|
|
|
<DT><CODE>file</CODE>
|
|
<DD><CODE>file</CODE> with no argument makes GDB discard any information it
|
|
has on both executable file and the symbol table.
|
|
<P>
|
|
|
|
<A NAME="IDX560"></A>
|
|
<DT><CODE>exec-file [ <VAR>filename</VAR> ]</CODE>
|
|
<DD>Specify that the program to be run (but not the symbol table) is found
|
|
in <VAR>filename</VAR>. GDB searches the environment variable <CODE>PATH</CODE>
|
|
if necessary to locate your program. Omitting <VAR>filename</VAR> means to
|
|
discard information on the executable file.
|
|
<P>
|
|
|
|
<A NAME="IDX561"></A>
|
|
<DT><CODE>symbol-file [ <VAR>filename</VAR> ]</CODE>
|
|
<DD>Read symbol table information from file <VAR>filename</VAR>. <CODE>PATH</CODE> is
|
|
searched when necessary. Use the <CODE>file</CODE> command to get both symbol
|
|
table and program to run from the same file.
|
|
<P>
|
|
|
|
<CODE>symbol-file</CODE> with no argument clears out GDB information on your
|
|
program's symbol table.
|
|
</P><P>
|
|
|
|
The <CODE>symbol-file</CODE> 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.
|
|
</P><P>
|
|
|
|
<CODE>symbol-file</CODE> does not repeat if you press <KBD>RET</KBD> again after
|
|
executing it once.
|
|
</P><P>
|
|
|
|
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 <CODE>gcc</CODE> you can generate debugging information for
|
|
optimized code.
|
|
</P><P>
|
|
|
|
For most kinds of object files, with the exception of old SVR3 systems
|
|
using COFF, the <CODE>symbol-file</CODE> 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.
|
|
</P><P>
|
|
|
|
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 <CODE>set verbose</CODE> command can turn these
|
|
pauses into messages if desired. See section <A HREF="gdb_20.html#SEC190">Optional warnings and messages</A>.)
|
|
</P><P>
|
|
|
|
We have not implemented the two-stage strategy for COFF yet. When the
|
|
symbol table is stored in COFF format, <CODE>symbol-file</CODE> 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.
|
|
</P><P>
|
|
|
|
<A NAME="IDX562"></A>
|
|
<A NAME="IDX563"></A>
|
|
<A NAME="IDX564"></A>
|
|
<A NAME="IDX565"></A>
|
|
<A NAME="IDX566"></A>
|
|
<A NAME="IDX567"></A>
|
|
<DT><CODE>symbol-file <VAR>filename</VAR> [ -readnow ] [ -mapped ]</CODE>
|
|
<DD><DT><CODE>file <VAR>filename</VAR> [ -readnow ] [ -mapped ]</CODE>
|
|
<DD>You can override the GDB two-stage strategy for reading symbol
|
|
tables by using the <SAMP>`-readnow'</SAMP> option with any of the commands that
|
|
load symbol table information, if you want to be sure GDB has the
|
|
entire symbol table available.
|
|
<P>
|
|
|
|
If memory-mapped files are available on your system through the
|
|
<CODE>mmap</CODE> system call, you can use another option, <SAMP>`-mapped'</SAMP>, 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 <SAMP>`-mapped'</SAMP> option has the same effect as
|
|
starting GDB with the <SAMP>`-mapped'</SAMP> command-line option.
|
|
</P><P>
|
|
|
|
You can use both options together, to make sure the auxiliary symbol
|
|
file has all the symbol information for your program.
|
|
</P><P>
|
|
|
|
The auxiliary symbol file for a program called <VAR>myprog</VAR> is called
|
|
<SAMP>`<VAR>myprog</VAR>.syms'</SAMP>. Once this file exists (so long as it is newer
|
|
than the corresponding executable), GDB always attempts to use
|
|
it when you debug <VAR>myprog</VAR>; no special options or commands are
|
|
needed.
|
|
</P><P>
|
|
|
|
The <TT>`.syms'</TT> 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.
|
|
</P><P>
|
|
|
|
<A NAME="IDX568"></A>
|
|
<A NAME="IDX569"></A>
|
|
<DT><CODE>core-file [ <VAR>filename</VAR> ]</CODE>
|
|
<DD>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.
|
|
<P>
|
|
|
|
<CODE>core-file</CODE> with no argument specifies that no core file is
|
|
to be used.
|
|
</P><P>
|
|
|
|
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 <CODE>kill</CODE> command
|
|
(see section <A HREF="gdb_5.html#SEC24">Killing the child process</A>).
|
|
</P><P>
|
|
|
|
<A NAME="IDX570"></A>
|
|
<A NAME="IDX571"></A>
|
|
<DT><CODE>add-symbol-file <VAR>filename</VAR> <VAR>address</VAR></CODE>
|
|
<DD><DT><CODE>add-symbol-file <VAR>filename</VAR> <VAR>address</VAR> [ -readnow ] [ -mapped ]</CODE>
|
|
<DD><DT><CODE>add-symbol-file <VAR>filename</VAR> -s<VAR>section</VAR> <VAR>address</VAR> <small>...</small></CODE>
|
|
<DD>The <CODE>add-symbol-file</CODE> command reads additional symbol table
|
|
information from the file <VAR>filename</VAR>. You would use this command
|
|
when <VAR>filename</VAR> has been dynamically loaded (by some other means)
|
|
into the program that is running. <VAR>address</VAR> 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 <SAMP>`-s<VAR>section</VAR> <VAR>address</VAR>'</SAMP> pairs, to give an explicit
|
|
section name and base address for that section. You can specify any
|
|
<VAR>address</VAR> as an expression.
|
|
<P>
|
|
|
|
The symbol table of the file <VAR>filename</VAR> is added to the symbol table
|
|
originally read with the <CODE>symbol-file</CODE> command. You can use the
|
|
<CODE>add-symbol-file</CODE> 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 <CODE>symbol-file</CODE> command without any arguments.
|
|
</P><P>
|
|
|
|
<A NAME="IDX572"></A>
|
|
<A NAME="IDX573"></A>
|
|
<A NAME="IDX574"></A>
|
|
<A NAME="IDX575"></A>
|
|
<A NAME="IDX576"></A>
|
|
Although <VAR>filename</VAR> 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 <TT>`.o'</TT> files, as long as:
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
the file's symbolic information refers only to linker symbols defined in
|
|
that file, not to symbols defined by other object files,
|
|
<LI>
|
|
every section the file's symbolic information refers to has actually
|
|
been loaded into the inferior, as it appears in the file, and
|
|
<LI>
|
|
you can determine the address at which every section was loaded, and
|
|
provide these to the <CODE>add-symbol-file</CODE> command.
|
|
</UL>
|
|
<P>
|
|
|
|
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 (<CODE>.linkonce</CODE> section factoring and C++ constructor table
|
|
assembly, for example) that make the requirements difficult to meet. In
|
|
general, one cannot assume that using <CODE>add-symbol-file</CODE> 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.
|
|
</P><P>
|
|
|
|
<CODE>add-symbol-file</CODE> does not repeat if you press <KBD>RET</KBD> after using it.
|
|
</P><P>
|
|
|
|
You can use the <SAMP>`-mapped'</SAMP> and <SAMP>`-readnow'</SAMP> options just as with
|
|
the <CODE>symbol-file</CODE> command, to change how GDB manages the symbol
|
|
table information for <VAR>filename</VAR>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX577"></A>
|
|
<DT><CODE>add-shared-symbol-file</CODE>
|
|
<DD>The <CODE>add-shared-symbol-file</CODE> 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
|
|
<CODE>add-shared-symbol-file</CODE>. It takes no arguments.
|
|
<P>
|
|
|
|
<A NAME="IDX578"></A>
|
|
<DT><CODE>section</CODE>
|
|
<DD>The <CODE>section</CODE> 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 <CODE>info files</CODE> command, described below, lists all
|
|
the sections and their addresses.
|
|
<P>
|
|
|
|
<A NAME="IDX579"></A>
|
|
<A NAME="IDX580"></A>
|
|
<DT><CODE>info files</CODE>
|
|
<DD><DT><CODE>info target</CODE>
|
|
<DD><CODE>info files</CODE> and <CODE>info target</CODE> are synonymous; both print the
|
|
current target (see section <A HREF="gdb_17.html#SEC130">Specifying a Debugging Target</A>),
|
|
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 <CODE>help target</CODE> lists all possible targets rather than
|
|
current ones.
|
|
<P>
|
|
|
|
<A NAME="IDX581"></A>
|
|
<DT><CODE>maint info sections</CODE>
|
|
<DD>Another command that can give you extra information about program sections
|
|
is <CODE>maint info sections</CODE>. In addition to the section information
|
|
displayed by <CODE>info files</CODE>, this command displays the flags and file
|
|
offset of each section in the executable and core dump files. In addition,
|
|
<CODE>maint info sections</CODE> provides the following command options (which
|
|
may be arbitrarily combined):
|
|
<P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>ALLOBJ</CODE>
|
|
<DD>Display sections for all loaded object files, including shared libraries.
|
|
<DT><CODE><VAR>sections</VAR></CODE>
|
|
<DD>Display info only for named <VAR>sections</VAR>.
|
|
<DT><CODE><VAR>section-flags</VAR></CODE>
|
|
<DD>Display info only for sections for which <VAR>section-flags</VAR> are true.
|
|
The section flags that GDB currently knows about are:
|
|
<DL COMPACT>
|
|
<DT><CODE>ALLOC</CODE>
|
|
<DD>Section will have space allocated in the process when loaded.
|
|
Set for all sections except those containing debug information.
|
|
<DT><CODE>LOAD</CODE>
|
|
<DD>Section will be loaded from the file into the child process memory.
|
|
Set for pre-initialized code and data, clear for <CODE>.bss</CODE> sections.
|
|
<DT><CODE>RELOC</CODE>
|
|
<DD>Section needs to be relocated before loading.
|
|
<DT><CODE>READONLY</CODE>
|
|
<DD>Section cannot be modified by the child process.
|
|
<DT><CODE>CODE</CODE>
|
|
<DD>Section contains executable code only.
|
|
<DT><CODE>DATA</CODE>
|
|
<DD>Section contains data only (no executable code).
|
|
<DT><CODE>ROM</CODE>
|
|
<DD>Section will reside in ROM.
|
|
<DT><CODE>CONSTRUCTOR</CODE>
|
|
<DD>Section contains data for constructor/destructor lists.
|
|
<DT><CODE>HAS_CONTENTS</CODE>
|
|
<DD>Section is not empty.
|
|
<DT><CODE>NEVER_LOAD</CODE>
|
|
<DD>An instruction to the linker to not output the section.
|
|
<DT><CODE>COFF_SHARED_LIBRARY</CODE>
|
|
<DD>A notification to the linker that the section contains
|
|
COFF shared library information.
|
|
<DT><CODE>IS_COMMON</CODE>
|
|
<DD>Section contains common symbols.
|
|
</DL>
|
|
</DL>
|
|
<A NAME="IDX582"></A>
|
|
<DT><CODE>set trust-readonly-sections on</CODE>
|
|
<DD>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.
|
|
<P>
|
|
|
|
The default is off.
|
|
</P><P>
|
|
|
|
<DT><CODE>set trust-readonly-sections off</CODE>
|
|
<DD>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.
|
|
</DL>
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
<A NAME="IDX583"></A>
|
|
GDB supports HP-UX, SunOS, SVr4, Irix 5, and IBM RS/6000 shared
|
|
libraries.
|
|
</P><P>
|
|
|
|
GDB automatically loads symbol definitions from shared libraries
|
|
when you use the <CODE>run</CODE> command, or when you examine a core file.
|
|
(Before you issue the <CODE>run</CODE> command, GDB does not understand
|
|
references to a function in a shared library, however--unless you are
|
|
debugging a core file).
|
|
</P><P>
|
|
|
|
On HP-UX, if the program loads a library explicitly, GDB
|
|
automatically loads the symbols at the time of the <CODE>shl_load</CODE> call.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
To control the automatic loading of shared library symbols, use the
|
|
commands:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX584"></A>
|
|
<DT><CODE>set auto-solib-add <VAR>mode</VAR></CODE>
|
|
<DD>If <VAR>mode</VAR> is <CODE>on</CODE>, 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 <VAR>mode</VAR>
|
|
is <CODE>off</CODE>, symbols must be loaded manually, using the
|
|
<CODE>sharedlibrary</CODE> command. The default value is <CODE>on</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX585"></A>
|
|
<DT><CODE>show auto-solib-add</CODE>
|
|
<DD>Display the current autoloading mode.
|
|
</DL>
|
|
<P>
|
|
|
|
To explicitly load shared library symbols, use the <CODE>sharedlibrary</CODE>
|
|
command:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX586"></A>
|
|
<A NAME="IDX587"></A>
|
|
<DT><CODE>info share</CODE>
|
|
<DD><DT><CODE>info sharedlibrary</CODE>
|
|
<DD>Print the names of the shared libraries which are currently loaded.
|
|
<P>
|
|
|
|
<A NAME="IDX588"></A>
|
|
<A NAME="IDX589"></A>
|
|
<DT><CODE>sharedlibrary <VAR>regex</VAR></CODE>
|
|
<DD><DT><CODE>share <VAR>regex</VAR></CODE>
|
|
<DD>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 <CODE>run</CODE>. If
|
|
<VAR>regex</VAR> is omitted all shared libraries required by your program are
|
|
loaded.
|
|
</DL>
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
Beyond that threshold, symbols from shared libraries must be explicitly
|
|
loaded. To load these symbols, use the command <CODE>sharedlibrary
|
|
<VAR>filename</VAR></CODE>. The base address of the shared library is determined
|
|
automatically by GDB and need not be specified.
|
|
</P><P>
|
|
|
|
To display or set the threshold, use the commands:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX590"></A>
|
|
<DT><CODE>set auto-solib-limit <VAR>threshold</VAR></CODE>
|
|
<DD>Set the autoloading size threshold, in an integral number of megabytes.
|
|
If <VAR>threshold</VAR> 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
|
|
<CODE>sharedlibrary</CODE> command. The default threshold is 100 (i.e. 100
|
|
Mb).
|
|
<P>
|
|
|
|
<A NAME="IDX591"></A>
|
|
<DT><CODE>show auto-solib-limit</CODE>
|
|
<DD>Display the current autoloading size threshold, in megabytes.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Symbol Errors"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC129"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_16.html#SEC128"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_17.html#SEC130"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_16.html#SEC127"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_16.html#SEC127"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_17.html#SEC130"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_35.html#SEC643">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.2 Errors reading symbol files </H2>
|
|
<!--docid::SEC129::-->
|
|
<P>
|
|
|
|
While reading a symbol file, GDB occasionally encounters problems,
|
|
such as symbol types it does not recognize, or known bugs in compiler
|
|
output. By default, GDB does not notify you of such problems, since
|
|
they are relatively common and primarily of interest to people
|
|
debugging compilers. If you are interested in seeing information
|
|
about ill-constructed symbol tables, you can either ask GDB to print
|
|
only one message about each such type of problem, no matter how many
|
|
times the problem occurs; or you can ask GDB to print more messages,
|
|
to see how many times the problems occur, with the <CODE>set
|
|
complaints</CODE> command (see section <A HREF="gdb_20.html#SEC190">Optional warnings and messages</A>).
|
|
</P><P>
|
|
|
|
The messages currently printed, and their meanings, include:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>inner block not inside outer block in <VAR>symbol</VAR></CODE>
|
|
<DD><P>
|
|
|
|
The symbol information shows where symbol scopes begin and end
|
|
(such as at the start of a function or a block of statements). This
|
|
error indicates that an inner scope block is not fully contained
|
|
in its outer scope blocks.
|
|
</P><P>
|
|
|
|
GDB circumvents the problem by treating the inner block as if it had
|
|
the same scope as the outer block. In the error message, <VAR>symbol</VAR>
|
|
may be shown as "<CODE>(don't know)</CODE>" if the outer block is not a
|
|
function.
|
|
</P><P>
|
|
|
|
<DT><CODE>block at <VAR>address</VAR> out of order</CODE>
|
|
<DD><P>
|
|
|
|
The symbol information for symbol scope blocks should occur in
|
|
order of increasing addresses. This error indicates that it does not
|
|
do so.
|
|
</P><P>
|
|
|
|
GDB does not circumvent this problem, and has trouble
|
|
locating symbols in the source file whose symbols it is reading. (You
|
|
can often determine what source file is affected by specifying
|
|
<CODE>set verbose on</CODE>. See section <A HREF="gdb_20.html#SEC190">Optional warnings and messages</A>.)
|
|
</P><P>
|
|
|
|
<DT><CODE>bad block start address patched</CODE>
|
|
<DD><P>
|
|
|
|
The symbol information for a symbol scope block has a start address
|
|
smaller than the address of the preceding source line. This is known
|
|
to occur in the SunOS 4.1.1 (and earlier) C compiler.
|
|
</P><P>
|
|
|
|
GDB circumvents the problem by treating the symbol scope block as
|
|
starting on the previous source line.
|
|
</P><P>
|
|
|
|
<DT><CODE>bad string table offset in symbol <VAR>n</VAR></CODE>
|
|
<DD><P>
|
|
|
|
<A NAME="IDX592"></A>
|
|
Symbol number <VAR>n</VAR> contains a pointer into the string table which is
|
|
larger than the size of the string table.
|
|
</P><P>
|
|
|
|
GDB circumvents the problem by considering the symbol to have the
|
|
name <CODE>foo</CODE>, which may cause other problems if many symbols end up
|
|
with this name.
|
|
</P><P>
|
|
|
|
<DT><CODE>unknown symbol type <CODE>0x<VAR>nn</VAR></CODE></CODE>
|
|
<DD><P>
|
|
|
|
The symbol information contains new data types that GDB does
|
|
not yet know how to read. <CODE>0x<VAR>nn</VAR></CODE> is the symbol type of the
|
|
uncomprehended information, in hexadecimal.
|
|
</P><P>
|
|
|
|
GDB circumvents the error by ignoring this symbol information.
|
|
This usually allows you to debug your program, though certain symbols
|
|
are not accessible. If you encounter such a problem and feel like
|
|
debugging it, you can debug <CODE>gdb</CODE> with itself, breakpoint
|
|
on <CODE>complain</CODE>, then go up to the function <CODE>read_dbx_symtab</CODE>
|
|
and examine <CODE>*bufp</CODE> to see the symbol.
|
|
</P><P>
|
|
|
|
<DT><CODE>stub type has NULL name</CODE>
|
|
<DD><P>
|
|
|
|
GDB could not find the full definition for a struct or class.
|
|
</P><P>
|
|
|
|
<DT><CODE>const/volatile indicator missing (ok if using g++ v1.x), got<small>...</small></CODE>
|
|
<DD>The symbol information for a C<TT>++</TT> member function is missing some
|
|
information that recent versions of the compiler should have output for
|
|
it.
|
|
<P>
|
|
|
|
<DT><CODE>info mismatch between compiler and debugger</CODE>
|
|
<DD><P>
|
|
|
|
GDB could not parse a type specification output by the compiler.
|
|
</P><P>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Targets"></A>
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_16.html#SEC127"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_17.html#SEC130"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_35.html#SEC643">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<BR>
|
|
<FONT SIZE="-1">
|
|
|
|
<address>
|
|
|
|
<p>Please send FSF & GNU inquiries & questions to <a
|
|
href="mailto:gnu@gnu.org">gnu@gnu.org</a>. There are also <a
|
|
href="http://www.gnu.org/home.html#ContactInfo">other ways to
|
|
contact</a> the FSF.</p>
|
|
|
|
<p>These pages are maintained by <a
|
|
href="http://www.gnu.org/software/gdb/">the GDB developers</a>.</p>
|
|
|
|
<p>Copyright Free Software Foundation, Inc., 59 Temple Place - Suite
|
|
330, Boston, MA 02111, USA.</p>
|
|
|
|
<p>Verbatim copying and distribution of this entire article is
|
|
permitted in any medium, provided this notice is preserved.</p>
|
|
|
|
</address>
|
|
|
|
This document was generated
|
|
by <I>GDB Administrator</I> on <I>November, 11 2002</I>
|
|
using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
|
|
"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|