12901 lines
407 KiB
HTML
12901 lines
407 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<!-- This HTML file has been created by texi2html 1.51
|
|
from gdb.texinfo on 23 April 1998 -->
|
|
|
|
<TITLE>Debugging with GDB</TITLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<H1>Debugging with GDB</H1>
|
|
<H2>The GNU Source-Level Debugger</H2>
|
|
<H2>Fifth Edition, for GDB version </H2>
|
|
<H2>April 1998</H2>
|
|
<ADDRESS>Richard M. Stallman and Roland H. Pesch</ADDRESS>
|
|
<P>
|
|
<P><HR><P>
|
|
|
|
<P>
|
|
|
|
<P>
|
|
Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998
|
|
Free Software Foundation, Inc.
|
|
<P>
|
|
Published by the Free Software Foundation <BR>
|
|
59 Temple Place - Suite 330, <BR>
|
|
Boston, MA 02111-1307 USA <BR>
|
|
Printed copies are available for $20 each. <BR>
|
|
ISBN 1-882114-11-6 <BR>
|
|
|
|
Permission is granted to make and distribute verbatim copies of
|
|
this manual provided the copyright notice and this permission notice
|
|
are preserved on all copies.
|
|
|
|
</P>
|
|
<P>
|
|
Permission is granted to copy and distribute modified versions of this
|
|
manual under the conditions for verbatim copying, provided also that the
|
|
entire resulting derived work is distributed under the terms of a
|
|
permission notice identical to this one.
|
|
|
|
</P>
|
|
<P>
|
|
Permission is granted to copy and distribute translations of this manual
|
|
into another language, under the above conditions for modified versions.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC1" HREF="gdb_toc.html#TOC1">Summary of GDB</A></H1>
|
|
|
|
<P>
|
|
The purpose of a debugger such as GDB is to allow you to see what is
|
|
going on "inside" another program while it executes--or what another
|
|
program was doing at the moment it crashed.
|
|
|
|
</P>
|
|
<P>
|
|
GDB can do four main kinds of things (plus other things in support of
|
|
these) to help you catch bugs in the act:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Start your program, specifying anything that might affect its behavior.
|
|
|
|
<LI>
|
|
|
|
Make your program stop on specified conditions.
|
|
|
|
<LI>
|
|
|
|
Examine what has happened, when your program has stopped.
|
|
|
|
<LI>
|
|
|
|
Change things in your program, so you can experiment with correcting the
|
|
effects of one bug and go on to learn about another.
|
|
</UL>
|
|
|
|
<P>
|
|
You can use GDB to debug programs written in C or C++.
|
|
For more information, see section <A HREF="gdb.html#SEC73">C and C++</A>.
|
|
|
|
</P>
|
|
<P>
|
|
Support for Modula-2 and Chill is partial. For information on Modula-2,
|
|
see section <A HREF="gdb.html#SEC81">Modula-2</A>. There is no further documentation on Chill yet.
|
|
|
|
</P>
|
|
<P>
|
|
Debugging Pascal programs which use sets, subranges, file variables, or nested
|
|
functions does not currently work. GDB does not support
|
|
entering expressions, printing values, or similar features using Pascal syntax.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX1"></A>
|
|
GDB can be used to debug programs written in Fortran, although
|
|
it does not yet support entering expressions, printing values, or
|
|
similar features using Fortran syntax. It may be necessary to refer to
|
|
some variables with a trailing underscore.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC2" HREF="gdb_toc.html#TOC2">Free software</A></H2>
|
|
|
|
<P>
|
|
GDB is <STRONG>free software</STRONG>, protected by the GNU
|
|
General Public License
|
|
(GPL). The GPL gives you the freedom to copy or adapt a licensed
|
|
program--but every person getting a copy also gets with it the
|
|
freedom to modify that copy (which means that they must get access to
|
|
the source code), and the freedom to distribute further copies.
|
|
Typical software companies use copyrights to limit your freedoms; the
|
|
Free Software Foundation uses the GPL to preserve these freedoms.
|
|
|
|
</P>
|
|
<P>
|
|
Fundamentally, the General Public License is a license which says that
|
|
you have these freedoms and that you cannot take these freedoms away
|
|
from anyone else.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC3" HREF="gdb_toc.html#TOC3">Contributors to GDB</A></H2>
|
|
|
|
<P>
|
|
Richard Stallman was the original author of GDB, and of many other GNU
|
|
programs. Many others have contributed to its development. This
|
|
section attempts to credit major contributors. One of the virtues of
|
|
free software is that everyone is free to contribute to it; with
|
|
regret, we cannot actually acknowledge everyone here. The file
|
|
<TT>`ChangeLog'</TT> in the GDB distribution approximates a blow-by-blow
|
|
account.
|
|
|
|
</P>
|
|
<P>
|
|
Changes much prior to version 2.0 are lost in the mists of time.
|
|
|
|
</P>
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Plea:</EM> Additions to this section are particularly welcome. If you
|
|
or your friends (or enemies, to be evenhanded) have been unfairly
|
|
omitted from this list, we would like to add your names!
|
|
</BLOCKQUOTE>
|
|
|
|
<P>
|
|
So that they may not regard their long labor as thankless, we
|
|
particularly thank those who shepherded GDB through major releases:
|
|
Stan Shebs (release 4.14),
|
|
Fred Fish (releases 4.13, 4.12, 4.11, 4.10, and 4.9),
|
|
Stu Grossman and John Gilmore (releases 4.8, 4.7, 4.6, 4.5, and 4.4),
|
|
John Gilmore (releases 4.3, 4.2, 4.1, 4.0, and 3.9);
|
|
Jim Kingdon (releases 3.5, 3.4, and 3.3);
|
|
and Randy Smith (releases 3.2, 3.1, and 3.0).
|
|
As major maintainer of GDB for some period, each
|
|
contributed significantly to the structure, stability, and capabilities
|
|
of the entire debugger.
|
|
|
|
</P>
|
|
<P>
|
|
Richard Stallman, assisted at various times by Peter TerMaat, Chris
|
|
Hanson, and Richard Mlynarik, handled releases through 2.8.
|
|
|
|
</P>
|
|
<P>
|
|
Michael Tiemann is the author of most of the GNU C++ support in GDB,
|
|
with significant additional contributions from Per Bothner. James
|
|
Clark wrote the GNU C++ demangler. Early work on C++ was by Peter
|
|
TerMaat (who also did much general update work leading to release 3.0).
|
|
|
|
</P>
|
|
<P>
|
|
GDB 4 uses the BFD subroutine library to examine multiple
|
|
object-file formats; BFD was a joint project of David V.
|
|
Henkel-Wallace, Rich Pixley, Steve Chamberlain, and John Gilmore.
|
|
|
|
</P>
|
|
<P>
|
|
David Johnson wrote the original COFF support; Pace Willison did
|
|
the original support for encapsulated COFF.
|
|
|
|
</P>
|
|
<P>
|
|
Brent Benson of Harris Computer Systems contributed DWARF 2 support.
|
|
|
|
</P>
|
|
<P>
|
|
Adam de Boor and Bradley Davis contributed the ISI Optimum V support.
|
|
Per Bothner, Noboyuki Hikichi, and Alessandro Forin contributed MIPS
|
|
support.
|
|
Jean-Daniel Fekete contributed Sun 386i support.
|
|
Chris Hanson improved the HP9000 support.
|
|
Noboyuki Hikichi and Tomoyuki Hasei contributed Sony/News OS 3 support.
|
|
David Johnson contributed Encore Umax support.
|
|
Jyrki Kuoppala contributed Altos 3068 support.
|
|
Jeff Law contributed HP PA and SOM support.
|
|
Keith Packard contributed NS32K support.
|
|
Doug Rabson contributed Acorn Risc Machine support.
|
|
Bob Rusk contributed Harris Nighthawk CX-UX support.
|
|
Chris Smith contributed Convex support (and Fortran debugging).
|
|
Jonathan Stone contributed Pyramid support.
|
|
Michael Tiemann contributed SPARC support.
|
|
Tim Tucker contributed support for the Gould NP1 and Gould Powernode.
|
|
Pace Willison contributed Intel 386 support.
|
|
Jay Vosburgh contributed Symmetry support.
|
|
|
|
</P>
|
|
<P>
|
|
Rich Schaefer and Peter Schauer helped with support of SunOS shared
|
|
libraries.
|
|
|
|
</P>
|
|
<P>
|
|
Jay Fenlason and Roland McGrath ensured that GDB and GAS agree about
|
|
several machine instruction sets.
|
|
|
|
</P>
|
|
<P>
|
|
Patrick Duval, Ted Goldstein, Vikram Koka and Glenn Engel helped develop
|
|
remote debugging. Intel Corporation, Wind River Systems, AMD, and ARM
|
|
contributed remote debugging modules for the i960, VxWorks, A29K UDI,
|
|
and RDI targets, respectively.
|
|
|
|
</P>
|
|
<P>
|
|
Brian Fox is the author of the readline libraries providing
|
|
command-line editing and command history.
|
|
|
|
</P>
|
|
<P>
|
|
Andrew Beers of SUNY Buffalo wrote the language-switching code,
|
|
the Modula-2 support,
|
|
and contributed the Languages chapter of this manual.
|
|
|
|
</P>
|
|
<P>
|
|
Fred Fish wrote most of the support for Unix System Vr4.
|
|
He also enhanced the command-completion support to cover C++ overloaded
|
|
symbols.
|
|
|
|
</P>
|
|
<P>
|
|
Hitachi America, Ltd. sponsored the support for Hitachi microprocessors.
|
|
|
|
</P>
|
|
<P>
|
|
Kung Hsu, Jeff Law, and Rick Sladkey added support for hardware
|
|
watchpoints.
|
|
|
|
</P>
|
|
<P>
|
|
Michael Snyder added support for tracepoints.
|
|
|
|
</P>
|
|
<P>
|
|
Stu Grossman wrote gdbserver.
|
|
|
|
</P>
|
|
<P>
|
|
Jim Kingdon, Peter Schauer, Ian Taylor, and Stu Grossman made
|
|
nearly innumerable bug fixes and cleanups throughout GDB.
|
|
|
|
</P>
|
|
<P>
|
|
Cygnus Solutions has sponsored GDB maintenance and much of its
|
|
development since 1991.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC4" HREF="gdb_toc.html#TOC4">A Sample GDB Session</A></H1>
|
|
|
|
<P>
|
|
You can use this manual at your leisure to read all about GDB.
|
|
However, a handful of commands are enough to get started using the
|
|
debugger. This chapter illustrates those commands.
|
|
|
|
</P>
|
|
<P>
|
|
In this sample session, we emphasize user input like this: <B>input</B>,
|
|
to make it easier to pick out from the surrounding output.
|
|
|
|
</P>
|
|
|
|
<P>
|
|
One of the preliminary versions of GNU <CODE>m4</CODE> (a generic macro
|
|
processor) exhibits the following bug: sometimes, when we change its
|
|
quote strings from the default, the commands used to capture one macro
|
|
definition within another stop working. In the following short <CODE>m4</CODE>
|
|
session, we define a macro <CODE>foo</CODE> which expands to <CODE>0000</CODE>; we
|
|
then use the <CODE>m4</CODE> built-in <CODE>defn</CODE> to define <CODE>bar</CODE> as the
|
|
same thing. However, when we change the open quote string to
|
|
<CODE><QUOTE></CODE> and the close quote string to <CODE><UNQUOTE></CODE>, the same
|
|
procedure fails to define a new synonym <CODE>baz</CODE>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$ <B>cd gnu/m4</B>
|
|
$ <B>./m4</B>
|
|
<B>define(foo,0000)</B>
|
|
|
|
<B>foo</B>
|
|
0000
|
|
<B>define(bar,defn(`foo'))</B>
|
|
|
|
<B>bar</B>
|
|
0000
|
|
<B>changequote(<QUOTE>,<UNQUOTE>)</B>
|
|
|
|
<B>define(baz,defn(<QUOTE>foo<UNQUOTE>))</B>
|
|
<B>baz</B>
|
|
<B>C-d</B>
|
|
m4: End of input: 0: fatal error: EOF in string
|
|
</PRE>
|
|
|
|
<P>
|
|
Let us use GDB to try to see what is going on.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$ <B>gdb m4</B>
|
|
GDB is free software and you are welcome to distribute copies
|
|
of it under certain conditions; type "show copying" to see
|
|
the conditions.
|
|
There is absolutely no warranty for GDB; type "show warranty"
|
|
for details.
|
|
|
|
GDB , Copyright 1995 Free Software Foundation, Inc...
|
|
(gdb)
|
|
</PRE>
|
|
|
|
<P>
|
|
GDB reads only enough symbol data to know where to find the
|
|
rest when needed; as a result, the first prompt comes up very quickly.
|
|
We now tell GDB to use a narrower display width than usual, so
|
|
that examples fit in this manual.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>set width 70</B>
|
|
</PRE>
|
|
|
|
<P>
|
|
We need to see how the <CODE>m4</CODE> built-in <CODE>changequote</CODE> works.
|
|
Having looked at the source, we know the relevant subroutine is
|
|
<CODE>m4_changequote</CODE>, so we set a breakpoint there with the GDB
|
|
<CODE>break</CODE> command.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>break m4_changequote</B>
|
|
Breakpoint 1 at 0x62f4: file builtin.c, line 879.
|
|
</PRE>
|
|
|
|
<P>
|
|
Using the <CODE>run</CODE> command, we start <CODE>m4</CODE> running under GDB
|
|
control; as long as control does not reach the <CODE>m4_changequote</CODE>
|
|
subroutine, the program runs as usual:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>run</B>
|
|
Starting program: /work/Editorial/gdb/gnu/m4/m4
|
|
<B>define(foo,0000)</B>
|
|
|
|
<B>foo</B>
|
|
0000
|
|
</PRE>
|
|
|
|
<P>
|
|
To trigger the breakpoint, we call <CODE>changequote</CODE>. GDB
|
|
suspends execution of <CODE>m4</CODE>, displaying information about the
|
|
context where it stops.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<B>changequote(<QUOTE>,<UNQUOTE>)</B>
|
|
|
|
Breakpoint 1, m4_changequote (argc=3, argv=0x33c70)
|
|
at builtin.c:879
|
|
879 if (bad_argc(TOKEN_DATA_TEXT(argv[0]),argc,1,3))
|
|
</PRE>
|
|
|
|
<P>
|
|
Now we use the command <CODE>n</CODE> (<CODE>next</CODE>) to advance execution to
|
|
the next line of the current function.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>n</B>
|
|
882 set_quotes((argc >= 2) ? TOKEN_DATA_TEXT(argv[1])\
|
|
: nil,
|
|
</PRE>
|
|
|
|
<P>
|
|
<CODE>set_quotes</CODE> looks like a promising subroutine. We can go into it
|
|
by using the command <CODE>s</CODE> (<CODE>step</CODE>) instead of <CODE>next</CODE>.
|
|
<CODE>step</CODE> goes to the next line to be executed in <EM>any</EM>
|
|
subroutine, so it steps into <CODE>set_quotes</CODE>.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>s</B>
|
|
set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "<UNQUOTE>")
|
|
at input.c:530
|
|
530 if (lquote != def_lquote)
|
|
</PRE>
|
|
|
|
<P>
|
|
The display that shows the subroutine where <CODE>m4</CODE> is now
|
|
suspended (and its arguments) is called a stack frame display. It
|
|
shows a summary of the stack. We can use the <CODE>backtrace</CODE>
|
|
command (which can also be spelled <CODE>bt</CODE>), to see where we are
|
|
in the stack as a whole: the <CODE>backtrace</CODE> command displays a
|
|
stack frame for each active subroutine.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>bt</B>
|
|
#0 set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "<UNQUOTE>")
|
|
at input.c:530
|
|
#1 0x6344 in m4_changequote (argc=3, argv=0x33c70)
|
|
at builtin.c:882
|
|
#2 0x8174 in expand_macro (sym=0x33320) at macro.c:242
|
|
#3 0x7a88 in expand_token (obs=0x0, t=209696, td=0xf7fffa30)
|
|
at macro.c:71
|
|
#4 0x79dc in expand_input () at macro.c:40
|
|
#5 0x2930 in main (argc=0, argv=0xf7fffb20) at m4.c:195
|
|
</PRE>
|
|
|
|
<P>
|
|
We step through a few more lines to see what happens. The first two
|
|
times, we can use <SAMP>`s'</SAMP>; the next two times we use <CODE>n</CODE> to avoid
|
|
falling into the <CODE>xstrdup</CODE> subroutine.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>s</B>
|
|
0x3b5c 532 if (rquote != def_rquote)
|
|
(gdb) <B>s</B>
|
|
0x3b80 535 lquote = (lq == nil || *lq == '\0') ? \
|
|
def_lquote : xstrdup(lq);
|
|
(gdb) <B>n</B>
|
|
536 rquote = (rq == nil || *rq == '\0') ? def_rquote\
|
|
: xstrdup(rq);
|
|
(gdb) <B>n</B>
|
|
538 len_lquote = strlen(rquote);
|
|
</PRE>
|
|
|
|
<P>
|
|
The last line displayed looks a little odd; we can examine the variables
|
|
<CODE>lquote</CODE> and <CODE>rquote</CODE> to see if they are in fact the new left
|
|
and right quotes we specified. We use the command <CODE>p</CODE>
|
|
(<CODE>print</CODE>) to see their values.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>p lquote</B>
|
|
$1 = 0x35d40 "<QUOTE>"
|
|
(gdb) <B>p rquote</B>
|
|
$2 = 0x35d50 "<UNQUOTE>"
|
|
</PRE>
|
|
|
|
<P>
|
|
<CODE>lquote</CODE> and <CODE>rquote</CODE> are indeed the new left and right quotes.
|
|
To look at some context, we can display ten lines of source
|
|
surrounding the current line with the <CODE>l</CODE> (<CODE>list</CODE>) command.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>l</B>
|
|
533 xfree(rquote);
|
|
534
|
|
535 lquote = (lq == nil || *lq == '\0') ? def_lquote\
|
|
: xstrdup (lq);
|
|
536 rquote = (rq == nil || *rq == '\0') ? def_rquote\
|
|
: xstrdup (rq);
|
|
537
|
|
538 len_lquote = strlen(rquote);
|
|
539 len_rquote = strlen(lquote);
|
|
540 }
|
|
541
|
|
542 void
|
|
</PRE>
|
|
|
|
<P>
|
|
Let us step past the two lines that set <CODE>len_lquote</CODE> and
|
|
<CODE>len_rquote</CODE>, and then examine the values of those variables.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>n</B>
|
|
539 len_rquote = strlen(lquote);
|
|
(gdb) <B>n</B>
|
|
540 }
|
|
(gdb) <B>p len_lquote</B>
|
|
$3 = 9
|
|
(gdb) <B>p len_rquote</B>
|
|
$4 = 7
|
|
</PRE>
|
|
|
|
<P>
|
|
That certainly looks wrong, assuming <CODE>len_lquote</CODE> and
|
|
<CODE>len_rquote</CODE> are meant to be the lengths of <CODE>lquote</CODE> and
|
|
<CODE>rquote</CODE> respectively. We can set them to better values using
|
|
the <CODE>p</CODE> command, since it can print the value of
|
|
any expression--and that expression can include subroutine calls and
|
|
assignments.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>p len_lquote=strlen(lquote)</B>
|
|
$5 = 7
|
|
(gdb) <B>p len_rquote=strlen(rquote)</B>
|
|
$6 = 9
|
|
</PRE>
|
|
|
|
<P>
|
|
Is that enough to fix the problem of using the new quotes with the
|
|
<CODE>m4</CODE> built-in <CODE>defn</CODE>? We can allow <CODE>m4</CODE> to continue
|
|
executing with the <CODE>c</CODE> (<CODE>continue</CODE>) command, and then try the
|
|
example that caused trouble initially:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>c</B>
|
|
Continuing.
|
|
|
|
<B>define(baz,defn(<QUOTE>foo<UNQUOTE>))</B>
|
|
|
|
baz
|
|
0000
|
|
</PRE>
|
|
|
|
<P>
|
|
Success! The new quotes now work just as well as the default ones. The
|
|
problem seems to have been just the two typos defining the wrong
|
|
lengths. We allow <CODE>m4</CODE> exit by giving it an EOF as input:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<B>C-d</B>
|
|
Program exited normally.
|
|
</PRE>
|
|
|
|
<P>
|
|
The message <SAMP>`Program exited normally.'</SAMP> is from GDB; it
|
|
indicates <CODE>m4</CODE> has finished executing. We can end our GDB
|
|
session with the GDB <CODE>quit</CODE> command.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) <B>quit</B>
|
|
</PRE>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC5" HREF="gdb_toc.html#TOC5">Getting In and Out of GDB</A></H1>
|
|
|
|
<P>
|
|
This chapter discusses how to start GDB, and how to get out of it.
|
|
The essentials are:
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
type <SAMP>`gdb'</SAMP> to start GDB.
|
|
<LI>
|
|
|
|
type <KBD>quit</KBD> or <KBD>C-d</KBD> to exit.
|
|
</UL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC6" HREF="gdb_toc.html#TOC6">Invoking GDB</A></H2>
|
|
|
|
<P>
|
|
Invoke GDB by running the program <CODE>gdb</CODE>. Once started,
|
|
GDB reads commands from the terminal until you tell it to exit.
|
|
|
|
</P>
|
|
<P>
|
|
You can also run <CODE>gdb</CODE> with a variety of arguments and options,
|
|
to specify more of your debugging environment at the outset.
|
|
|
|
</P>
|
|
<P>
|
|
The command-line options described here are designed
|
|
to cover a variety of situations; in some environments, some of these
|
|
options may effectively be unavailable.
|
|
|
|
</P>
|
|
<P>
|
|
The most usual way to start GDB is with one argument,
|
|
specifying an executable program:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
gdb <VAR>program</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
You can also start with both an executable program and a core file
|
|
specified:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
gdb <VAR>program</VAR> <VAR>core</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
You can, instead, specify a process ID as a second argument, if you want
|
|
to debug a running process:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
gdb <VAR>program</VAR> 1234
|
|
</PRE>
|
|
|
|
<P>
|
|
would attach GDB to process <CODE>1234</CODE> (unless you also have a file
|
|
named <TT>`1234'</TT>; GDB does check for a core file first).
|
|
|
|
</P>
|
|
<P>
|
|
Taking advantage of the second command-line argument requires a fairly
|
|
complete operating system; when you use GDB as a remote debugger
|
|
attached to a bare board, there may not be any notion of "process",
|
|
and there is often no way to get a core dump.
|
|
|
|
</P>
|
|
<P>
|
|
You can run <CODE>gdb</CODE> without printing the front material, which describes
|
|
GDB's non-warranty, by specifying <CODE>-silent</CODE>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
gdb <VAR>-silent</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
You can further control how GDB starts up by using command-line
|
|
options. GDB itself can remind you of the options available.
|
|
|
|
</P>
|
|
<P>
|
|
Type
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
gdb -help
|
|
</PRE>
|
|
|
|
<P>
|
|
to display all available options and briefly describe their use
|
|
(<SAMP>`gdb -h'</SAMP> is a shorter equivalent).
|
|
|
|
</P>
|
|
<P>
|
|
All options and command line arguments you give are processed
|
|
in sequential order. The order makes a difference when the
|
|
<SAMP>`-x'</SAMP> option is used.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC7" HREF="gdb_toc.html#TOC7">Choosing files</A></H3>
|
|
|
|
<P>
|
|
When GDB starts, it reads any arguments other than options as
|
|
specifying an executable file and core file (or process ID). This is
|
|
the same as if the arguments were specified by the <SAMP>`-se'</SAMP> and
|
|
<SAMP>`-c'</SAMP> options respectively. (GDB reads the first argument
|
|
that does not have an associated option flag as equivalent to the
|
|
<SAMP>`-se'</SAMP> option followed by that argument; and the second argument
|
|
that does not have an associated option flag, if any, as equivalent to
|
|
the <SAMP>`-c'</SAMP> option followed by that argument.)
|
|
|
|
</P>
|
|
<P>
|
|
Many options have both long and short forms; both are shown in the
|
|
following list. GDB also recognizes the long forms if you truncate
|
|
them, so long as enough of the option is present to be unambiguous.
|
|
(If you prefer, you can flag option arguments with <SAMP>`--'</SAMP> rather
|
|
than <SAMP>`-'</SAMP>, though we illustrate the more usual convention.)
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>-symbols <VAR>file</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>-s <VAR>file</VAR></CODE>
|
|
<DD>
|
|
Read symbol table from file <VAR>file</VAR>.
|
|
|
|
<DT><CODE>-exec <VAR>file</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>-e <VAR>file</VAR></CODE>
|
|
<DD>
|
|
Use file <VAR>file</VAR> as the executable file to execute when
|
|
appropriate, and for examining pure data in conjunction with a core
|
|
dump.
|
|
|
|
<DT><CODE>-se <VAR>file</VAR></CODE>
|
|
<DD>
|
|
Read symbol table from file <VAR>file</VAR> and use it as the executable
|
|
file.
|
|
|
|
<DT><CODE>-core <VAR>file</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>-c <VAR>file</VAR></CODE>
|
|
<DD>
|
|
Use file <VAR>file</VAR> as a core dump to examine.
|
|
|
|
<DT><CODE>-c <VAR>number</VAR></CODE>
|
|
<DD>
|
|
Connect to process ID <VAR>number</VAR>, as with the <CODE>attach</CODE> command
|
|
(unless there is a file in core-dump format named <VAR>number</VAR>, in which
|
|
case <SAMP>`-c'</SAMP> specifies that file as a core dump to read).
|
|
|
|
<DT><CODE>-command <VAR>file</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>-x <VAR>file</VAR></CODE>
|
|
<DD>
|
|
Execute GDB commands from file <VAR>file</VAR>. See section <A HREF="gdb.html#SEC148">Command files</A>.
|
|
|
|
<DT><CODE>-directory <VAR>directory</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>-d <VAR>directory</VAR></CODE>
|
|
<DD>
|
|
Add <VAR>directory</VAR> to the path to search for source files.
|
|
|
|
<DT><CODE>-m</CODE>
|
|
<DD>
|
|
<DT><CODE>-mapped</CODE>
|
|
<DD>
|
|
<EM>Warning: this option depends on operating system facilities that are not
|
|
supported on all systems.</EM><BR>
|
|
If memory-mapped files are available on your system through the <CODE>mmap</CODE>
|
|
system call, you can use this option
|
|
to have GDB write the symbols from your
|
|
program into a reusable file in the current directory. If the program you are debugging is
|
|
called <TT>`/tmp/fred'</TT>, the mapped symbol file is <TT>`./fred.syms'</TT>.
|
|
Future GDB debugging sessions notice the presence of this file,
|
|
and can quickly map in symbol information from it, rather than reading
|
|
the symbol table from the executable program.
|
|
|
|
The <TT>`.syms'</TT> file is specific to the host machine where GDB
|
|
is run. It holds an exact image of the internal GDB symbol
|
|
table. It cannot be shared across multiple host platforms.
|
|
|
|
<DT><CODE>-r</CODE>
|
|
<DD>
|
|
<DT><CODE>-readnow</CODE>
|
|
<DD>
|
|
Read each symbol file's entire symbol table immediately, rather than
|
|
the default, which is to read it incrementally as it is needed.
|
|
This makes startup slower, but makes future operations faster.
|
|
</DL>
|
|
|
|
<P>
|
|
The <CODE>-mapped</CODE> and <CODE>-readnow</CODE> options are typically combined in
|
|
order to build a <TT>`.syms'</TT> file that contains complete symbol
|
|
information. (See section <A HREF="gdb.html#SEC99">Commands to specify files</A>, for information
|
|
|
|
</P>
|
|
<P>
|
|
a <TT>`.syms'</TT> file for future use is:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
gdb -batch -nx -mapped -readnow programname
|
|
</PRE>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC8" HREF="gdb_toc.html#TOC8">Choosing modes</A></H3>
|
|
|
|
<P>
|
|
You can run GDB in various alternative modes--for example, in
|
|
batch mode or quiet mode.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>-nx</CODE>
|
|
<DD>
|
|
<DT><CODE>-n</CODE>
|
|
<DD>
|
|
Do not execute commands from any initialization files (normally called
|
|
<TT>`.gdbinit'</TT>). Normally, the commands in these files are
|
|
executed after all the command options and arguments have been
|
|
processed. See section <A HREF="gdb.html#SEC148">Command files</A>.
|
|
|
|
<DT><CODE>-quiet</CODE>
|
|
<DD>
|
|
<DT><CODE>-q</CODE>
|
|
<DD>
|
|
"Quiet". Do not print the introductory and copyright messages. These
|
|
messages are also suppressed in batch mode.
|
|
|
|
<DT><CODE>-batch</CODE>
|
|
<DD>
|
|
Run in batch mode. Exit with status <CODE>0</CODE> after processing all the
|
|
command files specified with <SAMP>`-x'</SAMP> (and all commands from
|
|
initialization files, if not inhibited with <SAMP>`-n'</SAMP>). Exit with
|
|
nonzero status if an error occurs in executing the GDB commands
|
|
in the command files.
|
|
|
|
Batch mode may be useful for running GDB as a filter, for example to
|
|
download and run a program on another computer; in order to make this
|
|
more useful, the message
|
|
|
|
|
|
<PRE>
|
|
Program exited normally.
|
|
</PRE>
|
|
|
|
(which is ordinarily issued whenever a program running under GDB control
|
|
terminates) is not issued when running in batch mode.
|
|
|
|
<DT><CODE>-cd <VAR>directory</VAR></CODE>
|
|
<DD>
|
|
Run GDB using <VAR>directory</VAR> as its working directory,
|
|
instead of the current directory.
|
|
|
|
<DT><CODE>-fullname</CODE>
|
|
<DD>
|
|
<DT><CODE>-f</CODE>
|
|
<DD>
|
|
GNU Emacs sets this option when it runs GDB as a subprocess. It tells GDB
|
|
to output the full file name and line number in a standard,
|
|
recognizable fashion each time a stack frame is displayed (which
|
|
includes each time your program stops). This recognizable format looks
|
|
like two <SAMP>`\032'</SAMP> characters, followed by the file name, line number
|
|
and character position separated by colons, and a newline. The
|
|
Emacs-to-GDB interface program uses the two <SAMP>`\032'</SAMP> characters as
|
|
a signal to display the source code for the frame.
|
|
|
|
<DT><CODE>-b <VAR>bps</VAR></CODE>
|
|
<DD>
|
|
Set the line speed (baud rate or bits per second) of any serial
|
|
interface used by GDB for remote debugging.
|
|
|
|
<DT><CODE>-tty <VAR>device</VAR></CODE>
|
|
<DD>
|
|
Run using <VAR>device</VAR> for your program's standard input and output.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC9" HREF="gdb_toc.html#TOC9">Quitting GDB</A></H2>
|
|
<P>
|
|
<A NAME="IDX2"></A>
|
|
<A NAME="IDX3"></A>
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>quit</CODE>
|
|
<DD>
|
|
<A NAME="IDX4"></A>
|
|
<A NAME="IDX5"></A>
|
|
|
|
To exit GDB, use the <CODE>quit</CODE> command (abbreviated <CODE>q</CODE>), or
|
|
type an end-of-file character (usually <KBD>C-d</KBD>). If you do not supply
|
|
<VAR>expression</VAR>, GDB will terminate normally; otherwise it will
|
|
terminate using the result of <VAR>expression</VAR> as the error code.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX6"></A>
|
|
An interrupt (often <KBD>C-c</KBD>) does not exit from GDB, but rather
|
|
terminates the action of any GDB command that is in progress and
|
|
returns to GDB command level. It is safe to type the interrupt
|
|
character at any time because GDB does not allow it to take effect
|
|
until a time when it is safe.
|
|
|
|
</P>
|
|
<P>
|
|
If you have been using GDB to control an attached process or
|
|
device, you can release it with the <CODE>detach</CODE> command
|
|
(see section <A HREF="gdb.html#SEC22">Debugging an already-running process</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC10" HREF="gdb_toc.html#TOC10">Shell commands</A></H2>
|
|
|
|
<P>
|
|
If you need to execute occasional shell commands during your
|
|
debugging session, there is no need to leave or suspend GDB; you can
|
|
just use the <CODE>shell</CODE> command.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>shell <VAR>command string</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX7"></A>
|
|
<A NAME="IDX8"></A>
|
|
|
|
Invoke a the standard shell to execute <VAR>command string</VAR>.
|
|
If it exists, the environment variable <CODE>SHELL</CODE> determines which
|
|
shell to run. Otherwise GDB uses <CODE>/bin/sh</CODE>.
|
|
</DL>
|
|
|
|
<P>
|
|
The utility <CODE>make</CODE> is often needed in development environments.
|
|
You do not have to use the <CODE>shell</CODE> command for this purpose in
|
|
GDB:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>make <VAR>make-args</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX9"></A>
|
|
<A NAME="IDX10"></A>
|
|
|
|
Execute the <CODE>make</CODE> program with the specified
|
|
arguments. This is equivalent to <SAMP>`shell make <VAR>make-args</VAR>'</SAMP>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC11" HREF="gdb_toc.html#TOC11">GDB Commands</A></H1>
|
|
|
|
<P>
|
|
You can abbreviate a GDB command to the first few letters of the command
|
|
name, if that abbreviation is unambiguous; and you can repeat certain
|
|
GDB commands by typing just <KBD>RET</KBD>. You can also use the <KBD>TAB</KBD>
|
|
key to get GDB to fill out the rest of a word in a command (or to
|
|
show you the alternatives available, if there is more than one possibility).
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC12" HREF="gdb_toc.html#TOC12">Command syntax</A></H2>
|
|
|
|
<P>
|
|
A GDB command is a single line of input. There is no limit on
|
|
how long it can be. It starts with a command name, which is followed by
|
|
arguments whose meaning depends on the command name. For example, the
|
|
command <CODE>step</CODE> accepts an argument which is the number of times to
|
|
step, as in <SAMP>`step 5'</SAMP>. You can also use the <CODE>step</CODE> command
|
|
with no arguments. Some command names do not allow any arguments.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX11"></A>
|
|
GDB command names may always be truncated if that abbreviation is
|
|
unambiguous. Other possible command abbreviations are listed in the
|
|
documentation for individual commands. In some cases, even ambiguous
|
|
abbreviations are allowed; for example, <CODE>s</CODE> is specially defined as
|
|
equivalent to <CODE>step</CODE> even though there are other commands whose
|
|
names start with <CODE>s</CODE>. You can test abbreviations by using them as
|
|
arguments to the <CODE>help</CODE> command.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX12"></A>
|
|
<A NAME="IDX13"></A>
|
|
A blank line as input to GDB (typing just <KBD>RET</KBD>) means to
|
|
repeat the previous command. Certain commands (for example, <CODE>run</CODE>)
|
|
will not repeat this way; these are commands whose unintentional
|
|
repetition might cause trouble and which you are unlikely to want to
|
|
repeat.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>list</CODE> and <CODE>x</CODE> commands, when you repeat them with
|
|
<KBD>RET</KBD>, construct new arguments rather than repeating
|
|
exactly as typed. This permits easy scanning of source or memory.
|
|
|
|
</P>
|
|
<P>
|
|
GDB can also use <KBD>RET</KBD> in another way: to partition lengthy
|
|
output, in a way similar to the common utility <CODE>more</CODE>
|
|
(see section <A HREF="gdb.html#SEC142">Screen size</A>). Since it is easy to press one
|
|
<KBD>RET</KBD> too many in this situation, GDB disables command
|
|
repetition after any command that generates this sort of display.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX14"></A>
|
|
<A NAME="IDX15"></A>
|
|
Any text from a <KBD>#</KBD> to the end of the line is a comment; it does
|
|
nothing. This is useful mainly in command files (see section <A HREF="gdb.html#SEC148">Command files</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC13" HREF="gdb_toc.html#TOC13">Command completion</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX16"></A>
|
|
<A NAME="IDX17"></A>
|
|
GDB can fill in the rest of a word in a command for you, if there is
|
|
only one possibility; it can also show you what the valid possibilities
|
|
are for the next word in a command, at any time. This works for GDB
|
|
commands, GDB subcommands, and the names of symbols in your program.
|
|
|
|
</P>
|
|
<P>
|
|
Press the <KBD>TAB</KBD> key whenever you want GDB to fill out the rest
|
|
of a word. If there is only one possibility, GDB fills in the
|
|
word, and waits for you to finish the command (or press <KBD>RET</KBD> to
|
|
enter it). For example, if you type
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) info bre <KBD>TAB</KBD>
|
|
</PRE>
|
|
|
|
<P>
|
|
GDB fills in the rest of the word <SAMP>`breakpoints'</SAMP>, since that is
|
|
the only <CODE>info</CODE> subcommand beginning with <SAMP>`bre'</SAMP>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) info breakpoints
|
|
</PRE>
|
|
|
|
<P>
|
|
You can either press <KBD>RET</KBD> at this point, to run the <CODE>info
|
|
breakpoints</CODE> command, or backspace and enter something else, if
|
|
<SAMP>`breakpoints'</SAMP> does not look like the command you expected. (If you
|
|
were sure you wanted <CODE>info breakpoints</CODE> in the first place, you
|
|
might as well just type <KBD>RET</KBD> immediately after <SAMP>`info bre'</SAMP>,
|
|
to exploit command abbreviations rather than command completion).
|
|
|
|
</P>
|
|
<P>
|
|
If there is more than one possibility for the next word when you press
|
|
<KBD>TAB</KBD>, GDB sounds a bell. You can either supply more
|
|
characters and try again, or just press <KBD>TAB</KBD> a second time;
|
|
GDB displays all the possible completions for that word. For
|
|
example, you might want to set a breakpoint on a subroutine whose name
|
|
begins with <SAMP>`make_'</SAMP>, but when you type <KBD>b make_<KBD>TAB</KBD></KBD> GDB
|
|
just sounds the bell. Typing <KBD>TAB</KBD> again displays all the
|
|
function names in your program that begin with those characters, for
|
|
example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) b make_ <KBD>TAB</KBD>
|
|
GDB sounds bell; press <KBD>TAB</KBD> again, to see:
|
|
make_a_section_from_file make_environ
|
|
make_abs_section make_function_type
|
|
make_blockvector make_pointer_type
|
|
make_cleanup make_reference_type
|
|
make_command make_symbol_completion_list
|
|
(gdb) b make_
|
|
</PRE>
|
|
|
|
<P>
|
|
After displaying the available possibilities, GDB copies your
|
|
partial input (<SAMP>`b make_'</SAMP> in the example) so you can finish the
|
|
command.
|
|
|
|
</P>
|
|
<P>
|
|
If you just want to see the list of alternatives in the first place, you
|
|
can press <KBD>M-?</KBD> rather than pressing <KBD>TAB</KBD> twice. <KBD>M-?</KBD>
|
|
means <KBD><KBD>META</KBD> ?</KBD>. You can type this
|
|
either by holding down a
|
|
key designated as the <KBD>META</KBD> shift on your keyboard (if there is
|
|
one) while typing <KBD>?</KBD>, or
|
|
as <KBD>ESC</KBD> followed by <KBD>?</KBD>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX18"></A>
|
|
<A NAME="IDX19"></A>
|
|
Sometimes the string you need, while logically a "word", may contain
|
|
parentheses or other characters that GDB normally excludes from its
|
|
notion of a word. To permit word completion to work in this situation,
|
|
you may enclose words in <CODE>'</CODE> (single quote marks) in GDB commands.
|
|
|
|
</P>
|
|
<P>
|
|
The most likely situation where you might need this is in typing the
|
|
name of a C++ function. This is because C++ allows function overloading
|
|
(multiple definitions of the same function, distinguished by argument
|
|
type). For example, when you want to set a breakpoint you may need to
|
|
distinguish whether you mean the version of <CODE>name</CODE> that takes an
|
|
<CODE>int</CODE> parameter, <CODE>name(int)</CODE>, or the version that takes a
|
|
<CODE>float</CODE> parameter, <CODE>name(float)</CODE>. To use the word-completion
|
|
facilities in this situation, type a single quote <CODE>'</CODE> at the
|
|
beginning of the function name. This alerts GDB that it may need to
|
|
consider more information than usual when you press <KBD>TAB</KBD> or
|
|
<KBD>M-?</KBD> to request word completion:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) b 'bubble( <KBD>M-?</KBD>
|
|
bubble(double,double) bubble(int,int)
|
|
(gdb) b 'bubble(
|
|
</PRE>
|
|
|
|
<P>
|
|
In some cases, GDB can tell that completing a name requires using
|
|
quotes. When this happens, GDB inserts the quote for you (while
|
|
completing as much as it can) if you do not type the quote in the first
|
|
place:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) b bub <KBD>TAB</KBD>
|
|
GDB alters your input line to the following, and rings a bell:
|
|
(gdb) b 'bubble(
|
|
</PRE>
|
|
|
|
<P>
|
|
In general, GDB can tell that a quote is needed (and inserts it) if
|
|
you have not yet started typing the argument list when you ask for
|
|
completion on an overloaded symbol.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC14" HREF="gdb_toc.html#TOC14">Getting help</A></H2>
|
|
<P>
|
|
<A NAME="IDX20"></A>
|
|
<A NAME="IDX21"></A>
|
|
|
|
</P>
|
|
<P>
|
|
You can always ask GDB itself for information on its commands,
|
|
using the command <CODE>help</CODE>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>help</CODE>
|
|
<DD>
|
|
<A NAME="IDX22"></A>
|
|
|
|
<DT><CODE>h</CODE>
|
|
<DD>
|
|
You can use <CODE>help</CODE> (abbreviated <CODE>h</CODE>) with no arguments to
|
|
display a short list of named classes of commands:
|
|
|
|
|
|
<PRE>
|
|
(gdb) help
|
|
List of classes of commands:
|
|
|
|
running -- Running the program
|
|
stack -- Examining the stack
|
|
data -- Examining data
|
|
breakpoints -- Making program stop at certain points
|
|
files -- Specifying and examining files
|
|
status -- Status inquiries
|
|
support -- Support facilities
|
|
user-defined -- User-defined commands
|
|
aliases -- Aliases of other commands
|
|
obscure -- Obscure features
|
|
|
|
Type "help" followed by a class name for a list of
|
|
commands in that class.
|
|
Type "help" followed by command name for full
|
|
documentation.
|
|
Command name abbreviations are allowed if unambiguous.
|
|
(gdb)
|
|
</PRE>
|
|
|
|
<DT><CODE>help <VAR>class</VAR></CODE>
|
|
<DD>
|
|
Using one of the general help classes as an argument, you can get a
|
|
list of the individual commands in that class. For example, here is the
|
|
help display for the class <CODE>status</CODE>:
|
|
|
|
|
|
<PRE>
|
|
(gdb) help status
|
|
Status inquiries.
|
|
|
|
List of commands:
|
|
|
|
show -- Generic command for showing things set
|
|
with "set"
|
|
info -- Generic command for printing status
|
|
|
|
Type "help" followed by command name for full
|
|
documentation.
|
|
Command name abbreviations are allowed if unambiguous.
|
|
(gdb)
|
|
</PRE>
|
|
|
|
<DT><CODE>help <VAR>command</VAR></CODE>
|
|
<DD>
|
|
With a command name as <CODE>help</CODE> argument, GDB displays a
|
|
short paragraph on how to use that command.
|
|
|
|
<A NAME="IDX23"></A>
|
|
<DT><CODE>complete <VAR>args</VAR></CODE>
|
|
<DD>
|
|
The <CODE>complete <VAR>args</VAR></CODE> command lists all the possible completions
|
|
for the beginning of a command. Use <VAR>args</VAR> to specify the beginning of the
|
|
command you want completed. For example:
|
|
|
|
|
|
<PRE>
|
|
complete i
|
|
</PRE>
|
|
|
|
results in:
|
|
|
|
|
|
<PRE>
|
|
info
|
|
inspect
|
|
ignore
|
|
</PRE>
|
|
|
|
This is intended for use by GNU Emacs.
|
|
</DL>
|
|
|
|
<P>
|
|
In addition to <CODE>help</CODE>, you can use the GDB commands <CODE>info</CODE>
|
|
and <CODE>show</CODE> to inquire about the state of your program, or the state
|
|
of GDB itself. Each command supports many topics of inquiry; this
|
|
manual introduces each of them in the appropriate context. The listings
|
|
under <CODE>info</CODE> and under <CODE>show</CODE> in the Index point to
|
|
all the sub-commands. See section <A HREF="gdb.html#SEC159">Index</A>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info</CODE>
|
|
<DD>
|
|
<A NAME="IDX24"></A>
|
|
<A NAME="IDX25"></A>
|
|
|
|
This command (abbreviated <CODE>i</CODE>) is for describing the state of your
|
|
program. For example, you can list the arguments given to your program
|
|
with <CODE>info args</CODE>, list the registers currently in use with <CODE>info
|
|
registers</CODE>, or list the breakpoints you have set with <CODE>info breakpoints</CODE>.
|
|
You can get a complete list of the <CODE>info</CODE> sub-commands with
|
|
<CODE>help info</CODE>.
|
|
|
|
<A NAME="IDX26"></A>
|
|
<DT><CODE>set</CODE>
|
|
<DD>
|
|
You can assign the result of an expresson to an environment variable with
|
|
<CODE>set</CODE>. For example, you can set the GDB prompt to a $-sign with
|
|
<CODE>set prompt $</CODE>.
|
|
|
|
<A NAME="IDX27"></A>
|
|
<DT><CODE>show</CODE>
|
|
<DD>
|
|
In contrast to <CODE>info</CODE>, <CODE>show</CODE> is for describing the state of
|
|
GDB itself.
|
|
You can change most of the things you can <CODE>show</CODE>, by using the
|
|
related command <CODE>set</CODE>; for example, you can control what number
|
|
system is used for displays with <CODE>set radix</CODE>, or simply inquire
|
|
which is currently in use with <CODE>show radix</CODE>.
|
|
|
|
<A NAME="IDX28"></A>
|
|
To display all the settable parameters and their current
|
|
values, you can use <CODE>show</CODE> with no arguments; you may also use
|
|
<CODE>info set</CODE>. Both commands produce the same display.
|
|
</DL>
|
|
|
|
<P>
|
|
Here are three miscellaneous <CODE>show</CODE> subcommands, all of which are
|
|
exceptional in lacking corresponding <CODE>set</CODE> commands:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>show version</CODE>
|
|
<DD>
|
|
<A NAME="IDX29"></A>
|
|
<A NAME="IDX30"></A>
|
|
|
|
Show what version of GDB is running. You should include this
|
|
information in GDB bug-reports. If multiple versions of GDB are in
|
|
use at your site, you may occasionally want to determine which version
|
|
of GDB you are running; as GDB evolves, new commands are introduced,
|
|
and old ones may wither away. The version number is also announced
|
|
when you start GDB.
|
|
|
|
<A NAME="IDX31"></A>
|
|
<DT><CODE>show copying</CODE>
|
|
<DD>
|
|
Display information about permission for copying GDB.
|
|
|
|
<A NAME="IDX32"></A>
|
|
<DT><CODE>show warranty</CODE>
|
|
<DD>
|
|
Display the GNU "NO WARRANTY" statement.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC15" HREF="gdb_toc.html#TOC15">Running Programs Under GDB</A></H1>
|
|
|
|
<P>
|
|
When you run a program under GDB, you must first generate
|
|
debugging information when you compile it.
|
|
You may start GDB with its arguments, if any, in an environment
|
|
of your choice. You may redirect your program's input and output, debug an
|
|
already running process, or kill a child process.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC16" HREF="gdb_toc.html#TOC16">Compiling for debugging</A></H2>
|
|
|
|
<P>
|
|
In order to debug a program effectively, you need to generate
|
|
debugging information when you compile it. This debugging information
|
|
is stored in the object file; it describes the data type of each
|
|
variable or function and the correspondence between source line numbers
|
|
and addresses in the executable code.
|
|
|
|
</P>
|
|
<P>
|
|
To request debugging information, specify the <SAMP>`-g'</SAMP> option when you run
|
|
the compiler.
|
|
|
|
</P>
|
|
<P>
|
|
Many C compilers are unable to handle the <SAMP>`-g'</SAMP> and <SAMP>`-O'</SAMP>
|
|
options together. Using those compilers, you cannot generate optimized
|
|
executables containing debugging information.
|
|
|
|
</P>
|
|
<P>
|
|
GCC, the GNU C compiler, supports <SAMP>`-g'</SAMP> with or without
|
|
<SAMP>`-O'</SAMP>, making it possible to debug optimized code. We recommend
|
|
that you <EM>always</EM> use <SAMP>`-g'</SAMP> whenever you compile a program.
|
|
You may think your program is correct, but there is no sense in pushing
|
|
your luck.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX33"></A>
|
|
<A NAME="IDX34"></A>
|
|
When you debug a program compiled with <SAMP>`-g -O'</SAMP>, remember that the
|
|
optimizer is rearranging your code; the debugger shows you what is
|
|
really there. Do not be too surprised when the execution path does not
|
|
exactly match your source file! An extreme example: if you define a
|
|
variable, but never use it, GDB never sees that
|
|
variable--because the compiler optimizes it out of existence.
|
|
|
|
</P>
|
|
<P>
|
|
Some things do not work as well with <SAMP>`-g -O'</SAMP> as with just
|
|
<SAMP>`-g'</SAMP>, particularly on machines with instruction scheduling. If in
|
|
doubt, recompile with <SAMP>`-g'</SAMP> alone, and if this fixes the problem,
|
|
please report it to us as a bug (including a test case!).
|
|
|
|
</P>
|
|
<P>
|
|
Older versions of the GNU C compiler permitted a variant option
|
|
<SAMP>`-gg'</SAMP> for debugging information. GDB no longer supports this
|
|
format; if your GNU C compiler has this option, do not use it.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC17" HREF="gdb_toc.html#TOC17">Starting your program</A></H2>
|
|
<P>
|
|
<A NAME="IDX35"></A>
|
|
<A NAME="IDX36"></A>
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>run</CODE>
|
|
<DD>
|
|
<A NAME="IDX37"></A>
|
|
|
|
<DT><CODE>r</CODE>
|
|
<DD>
|
|
Use the <CODE>run</CODE> command to start your program under GDB. You must
|
|
first specify the program name
|
|
(except on VxWorks)
|
|
with an argument to GDB (see section <A HREF="gdb.html#SEC5">Getting In and Out of GDB</A>), or by using the <CODE>file</CODE> or <CODE>exec-file</CODE>
|
|
command (see section <A HREF="gdb.html#SEC99">Commands to specify files</A>).
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
If you are running your program in an execution environment that
|
|
supports processes, <CODE>run</CODE> creates an inferior process and makes
|
|
that process run your program. (In environments without processes,
|
|
<CODE>run</CODE> jumps to the start of your program.)
|
|
|
|
</P>
|
|
<P>
|
|
The execution of a program is affected by certain information it
|
|
receives from its superior. GDB provides ways to specify this
|
|
information, which you must do <EM>before</EM> starting your program. (You
|
|
can change it after starting your program, but such changes only affect
|
|
your program the next time you start it.) This information may be
|
|
divided into four categories:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT>The <EM>arguments.</EM>
|
|
<DD>
|
|
Specify the arguments to give your program as the arguments of the
|
|
<CODE>run</CODE> command. If a shell is available on your target, the shell
|
|
is used to pass the arguments, so that you may use normal conventions
|
|
(such as wildcard expansion or variable substitution) in describing
|
|
the arguments. In Unix systems, you can control which shell is used
|
|
with the <CODE>SHELL</CODE> environment variable. See section <A HREF="gdb.html#SEC18">Your program's arguments</A>.
|
|
|
|
<DT>The <EM>environment.</EM>
|
|
<DD>
|
|
Your program normally inherits its environment from GDB, but you can
|
|
use the GDB commands <CODE>set environment</CODE> and <CODE>unset
|
|
environment</CODE> to change parts of the environment that affect
|
|
your program. See section <A HREF="gdb.html#SEC19">Your program's environment</A>.
|
|
|
|
<DT>The <EM>working directory.</EM>
|
|
<DD>
|
|
Your program inherits its working directory from GDB. You can set
|
|
the GDB working directory with the <CODE>cd</CODE> command in GDB.
|
|
See section <A HREF="gdb.html#SEC20">Your program's working directory</A>.
|
|
|
|
<DT>The <EM>standard input and output.</EM>
|
|
<DD>
|
|
Your program normally uses the same device for standard input and
|
|
standard output as GDB is using. You can redirect input and output
|
|
in the <CODE>run</CODE> command line, or you can use the <CODE>tty</CODE> command to
|
|
set a different device for your program.
|
|
See section <A HREF="gdb.html#SEC21">Your program's input and output</A>.
|
|
|
|
<A NAME="IDX38"></A>
|
|
<EM>Warning:</EM> While input and output redirection work, you cannot use
|
|
pipes to pass the output of the program you are debugging to another
|
|
program; if you attempt this, GDB is likely to wind up debugging the
|
|
wrong program.
|
|
</DL>
|
|
|
|
<P>
|
|
When you issue the <CODE>run</CODE> command, your program begins to execute
|
|
immediately. See section <A HREF="gdb.html#SEC27">Stopping and Continuing</A>, for discussion
|
|
of how to arrange for your program to stop. Once your program has
|
|
stopped, you may call functions in your program, using the <CODE>print</CODE>
|
|
or <CODE>call</CODE> commands. See section <A HREF="gdb.html#SEC51">Examining Data</A>.
|
|
|
|
</P>
|
|
<P>
|
|
If the modification time of your symbol file has changed since the last
|
|
time GDB read its symbols, GDB discards its symbol
|
|
table, and reads it again. When it does this, GDB tries to retain
|
|
your current breakpoints.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC18" HREF="gdb_toc.html#TOC18">Your program's arguments</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX39"></A>
|
|
The arguments to your program can be specified by the arguments of the
|
|
<CODE>run</CODE> command. They are passed to a shell, which expands wildcard
|
|
characters and performs redirection of I/O, and thence to your program.
|
|
Your <CODE>SHELL</CODE> environment variable (if it exists) specifies what
|
|
shell GDB uses. If you do not define <CODE>SHELL</CODE>,
|
|
GDB uses <CODE>/bin/sh</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
<CODE>run</CODE> with no arguments uses the same arguments used by the previous
|
|
<CODE>run</CODE>, or those set by the <CODE>set args</CODE> command.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX40"></A>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set args</CODE>
|
|
<DD>
|
|
Specify the arguments to be used the next time your program is run. If
|
|
<CODE>set args</CODE> has no arguments, <CODE>run</CODE> executes your program
|
|
with no arguments. Once you have run your program with arguments,
|
|
using <CODE>set args</CODE> before the next <CODE>run</CODE> is the only way to run
|
|
it again without arguments.
|
|
|
|
<A NAME="IDX41"></A>
|
|
<DT><CODE>show args</CODE>
|
|
<DD>
|
|
Show the arguments to give your program when it is started.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC19" HREF="gdb_toc.html#TOC19">Your program's environment</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX42"></A>
|
|
The <STRONG>environment</STRONG> consists of a set of environment variables and
|
|
their values. Environment variables conventionally record such things as
|
|
your user name, your home directory, your terminal type, and your search
|
|
path for programs to run. Usually you set up environment variables with
|
|
the shell and they are inherited by all the other programs you run. When
|
|
debugging, it can be useful to try running your program with a modified
|
|
environment without having to start GDB over again.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>path <VAR>directory</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX43"></A>
|
|
|
|
Add <VAR>directory</VAR> to the front of the <CODE>PATH</CODE> environment variable
|
|
(the search path for executables), for both GDB and your program.
|
|
You may specify several directory names, separated by <SAMP>`:'</SAMP> or
|
|
whitespace. If <VAR>directory</VAR> is already in the path, it is moved to
|
|
the front, so it is searched sooner.
|
|
|
|
You can use the string <SAMP>`$cwd'</SAMP> to refer to whatever is the current
|
|
working directory at the time GDB searches the path. If you
|
|
use <SAMP>`.'</SAMP> instead, it refers to the directory where you executed the
|
|
<CODE>path</CODE> command. GDB replaces <SAMP>`.'</SAMP> in the
|
|
<VAR>directory</VAR> argument (with the current path) before adding
|
|
<VAR>directory</VAR> to the search path.
|
|
|
|
<A NAME="IDX44"></A>
|
|
<DT><CODE>show paths</CODE>
|
|
<DD>
|
|
Display the list of search paths for executables (the <CODE>PATH</CODE>
|
|
environment variable).
|
|
|
|
<A NAME="IDX45"></A>
|
|
<DT><CODE>show environment [<VAR>varname</VAR>]</CODE>
|
|
<DD>
|
|
Print the value of environment variable <VAR>varname</VAR> to be given to
|
|
your program when it starts. If you do not supply <VAR>varname</VAR>,
|
|
print the names and values of all environment variables to be given to
|
|
your program. You can abbreviate <CODE>environment</CODE> as <CODE>env</CODE>.
|
|
|
|
<A NAME="IDX46"></A>
|
|
<DT><CODE>set environment <VAR>varname</VAR> [=] <VAR>value</VAR></CODE>
|
|
<DD>
|
|
Set environment variable <VAR>varname</VAR> to <VAR>value</VAR>. The value
|
|
changes for your program only, not for GDB itself. <VAR>value</VAR> may
|
|
be any string; the values of environment variables are just strings, and
|
|
any interpretation is supplied by your program itself. The <VAR>value</VAR>
|
|
parameter is optional; if it is eliminated, the variable is set to a
|
|
null value.
|
|
|
|
For example, this command:
|
|
|
|
|
|
<PRE>
|
|
set env USER = foo
|
|
</PRE>
|
|
|
|
tells a Unix program, when subsequently run, that its user is named
|
|
<SAMP>`foo'</SAMP>. (The spaces around <SAMP>`='</SAMP> are used for clarity here; they
|
|
are not actually required.)
|
|
|
|
<A NAME="IDX47"></A>
|
|
<DT><CODE>unset environment <VAR>varname</VAR></CODE>
|
|
<DD>
|
|
Remove variable <VAR>varname</VAR> from the environment to be passed to your
|
|
program. This is different from <SAMP>`set env <VAR>varname</VAR> ='</SAMP>;
|
|
<CODE>unset environment</CODE> removes the variable from the environment,
|
|
rather than assigning it an empty value.
|
|
</DL>
|
|
|
|
<P>
|
|
<EM>Warning:</EM> GDB runs your program using the shell indicated
|
|
by your <CODE>SHELL</CODE> environment variable if it exists (or
|
|
<CODE>/bin/sh</CODE> if not). If your <CODE>SHELL</CODE> variable names a shell
|
|
that runs an initialization file--such as <TT>`.cshrc'</TT> for C-shell, or
|
|
<TT>`.bashrc'</TT> for BASH--any variables you set in that file affect
|
|
your program. You may wish to move setting of environment variables to
|
|
files that are only run when you sign on, such as <TT>`.login'</TT> or
|
|
<TT>`.profile'</TT>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC20" HREF="gdb_toc.html#TOC20">Your program's working directory</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX48"></A>
|
|
Each time you start your program with <CODE>run</CODE>, it inherits its
|
|
working directory from the current working directory of GDB.
|
|
The GDB working directory is initially whatever it inherited
|
|
from its parent process (typically the shell), but you can specify a new
|
|
working directory in GDB with the <CODE>cd</CODE> command.
|
|
|
|
</P>
|
|
<P>
|
|
The GDB working directory also serves as a default for the commands
|
|
that specify files for GDB to operate on. See section <A HREF="gdb.html#SEC99">Commands to specify files</A>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>cd <VAR>directory</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX49"></A>
|
|
|
|
Set the GDB working directory to <VAR>directory</VAR>.
|
|
|
|
<A NAME="IDX50"></A>
|
|
<DT><CODE>pwd</CODE>
|
|
<DD>
|
|
Print the GDB working directory.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC21" HREF="gdb_toc.html#TOC21">Your program's input and output</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX51"></A>
|
|
<A NAME="IDX52"></A>
|
|
<A NAME="IDX53"></A>
|
|
By default, the program you run under GDB does input and output to
|
|
the same terminal that GDB uses. GDB switches the terminal
|
|
to its own terminal modes to interact with you, but it records the terminal
|
|
modes your program was using and switches back to them when you continue
|
|
running your program.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info terminal</CODE>
|
|
<DD>
|
|
<A NAME="IDX54"></A>
|
|
|
|
Displays information recorded by GDB about the terminal modes your
|
|
program is using.
|
|
</DL>
|
|
|
|
<P>
|
|
You can redirect your program's input and/or output using shell
|
|
redirection with the <CODE>run</CODE> command. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
run > outfile
|
|
</PRE>
|
|
|
|
<P>
|
|
starts your program, diverting its output to the file <TT>`outfile'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX55"></A>
|
|
<A NAME="IDX56"></A>
|
|
Another way to specify where your program should do input and output is
|
|
with the <CODE>tty</CODE> command. This command accepts a file name as
|
|
argument, and causes this file to be the default for future <CODE>run</CODE>
|
|
commands. It also resets the controlling terminal for the child
|
|
process, for future <CODE>run</CODE> commands. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
tty /dev/ttyb
|
|
</PRE>
|
|
|
|
<P>
|
|
directs that processes started with subsequent <CODE>run</CODE> commands
|
|
default to do input and output on the terminal <TT>`/dev/ttyb'</TT> and have
|
|
that as their controlling terminal.
|
|
|
|
</P>
|
|
<P>
|
|
An explicit redirection in <CODE>run</CODE> overrides the <CODE>tty</CODE> command's
|
|
effect on the input/output device, but not its effect on the controlling
|
|
terminal.
|
|
|
|
</P>
|
|
<P>
|
|
When you use the <CODE>tty</CODE> command or redirect input in the <CODE>run</CODE>
|
|
command, only the input <EM>for your program</EM> is affected. The input
|
|
for GDB still comes from your terminal.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC22" HREF="gdb_toc.html#TOC22">Debugging an already-running process</A></H2>
|
|
<P>
|
|
<A NAME="IDX57"></A>
|
|
<A NAME="IDX58"></A>
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>attach <VAR>process-id</VAR></CODE>
|
|
<DD>
|
|
This command attaches to a running process--one that was started
|
|
outside GDB. (<CODE>info files</CODE> shows your active
|
|
targets.) The command takes as argument a process ID. The usual way to
|
|
find out the process-id of a Unix process is with the <CODE>ps</CODE> utility,
|
|
or with the <SAMP>`jobs -l'</SAMP> shell command.
|
|
|
|
<CODE>attach</CODE> does not repeat if you press <KBD>RET</KBD> a second time after
|
|
executing the command.
|
|
</DL>
|
|
|
|
<P>
|
|
To use <CODE>attach</CODE>, your program must be running in an environment
|
|
which supports processes; for example, <CODE>attach</CODE> does not work for
|
|
programs on bare-board targets that lack an operating system. You must
|
|
also have permission to send the process a signal.
|
|
|
|
</P>
|
|
<P>
|
|
When using <CODE>attach</CODE>, you should first use the <CODE>file</CODE> command
|
|
to specify the program running in the process and load its symbol table.
|
|
See section <A HREF="gdb.html#SEC99">Commands to specify files</A>.
|
|
|
|
</P>
|
|
<P>
|
|
The first thing GDB does after arranging to debug the specified
|
|
process is to stop it. You can examine and modify an attached process
|
|
with all the GDB commands that are ordinarily available when you start
|
|
processes with <CODE>run</CODE>. You can insert breakpoints; you can step and
|
|
continue; you can modify storage. If you would rather the process
|
|
continue running, you may use the <CODE>continue</CODE> command after
|
|
attaching GDB to the process.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>detach</CODE>
|
|
<DD>
|
|
<A NAME="IDX59"></A>
|
|
|
|
When you have finished debugging the attached process, you can use the
|
|
<CODE>detach</CODE> command to release it from GDB control. Detaching
|
|
the process continues its execution. After the <CODE>detach</CODE> command,
|
|
that process and GDB become completely independent once more, and you
|
|
are ready to <CODE>attach</CODE> another process or start one with <CODE>run</CODE>.
|
|
<CODE>detach</CODE> does not repeat if you press <KBD>RET</KBD> again after
|
|
executing the command.
|
|
</DL>
|
|
|
|
<P>
|
|
If you exit GDB or use the <CODE>run</CODE> command while you have an
|
|
attached process, you kill that process. By default, GDB asks
|
|
for confirmation if you try to do either of these things; you can
|
|
control whether or not you need to confirm by using the <CODE>set
|
|
confirm</CODE> command (see section <A HREF="gdb.html#SEC144">Optional warnings and messages</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC23" HREF="gdb_toc.html#TOC23">Killing the child process</A></H2>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>kill</CODE>
|
|
<DD>
|
|
<A NAME="IDX60"></A>
|
|
|
|
Kill the child process in which your program is running under GDB.
|
|
</DL>
|
|
|
|
<P>
|
|
This command is useful if you wish to debug a core dump instead of a
|
|
running process. GDB ignores any core dump file while your program
|
|
is running.
|
|
|
|
</P>
|
|
<P>
|
|
On some operating systems, a program cannot be executed outside GDB
|
|
while you have breakpoints set on it inside GDB. You can use the
|
|
<CODE>kill</CODE> command in this situation to permit running your program
|
|
outside the debugger.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>kill</CODE> command is also useful if you wish to recompile and
|
|
relink your program, since on many systems it is impossible to modify an
|
|
executable file while it is running in a process. In this case, when you
|
|
next type <CODE>run</CODE>, GDB notices that the file has changed, and
|
|
reads the symbol table again (while trying to preserve your current
|
|
breakpoint settings).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC24" HREF="gdb_toc.html#TOC24">Additional process information</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX61"></A>
|
|
<A NAME="IDX62"></A>
|
|
Some operating systems provide a facility called <SAMP>`/proc'</SAMP> that can
|
|
be used to examine the image of a running process using file-system
|
|
subroutines. If GDB is configured for an operating system with this
|
|
facility, the command <CODE>info proc</CODE> is available to report on several
|
|
kinds of information about the process running your program.
|
|
<CODE>info proc</CODE> works only on SVR4 systems that support <CODE>procfs</CODE>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info proc</CODE>
|
|
<DD>
|
|
<A NAME="IDX63"></A>
|
|
|
|
Summarize available information about the process.
|
|
|
|
<A NAME="IDX64"></A>
|
|
<DT><CODE>info proc mappings</CODE>
|
|
<DD>
|
|
Report on the address ranges accessible in the program, with information
|
|
on whether your program may read, write, or execute each range.
|
|
|
|
<A NAME="IDX65"></A>
|
|
<DT><CODE>info proc times</CODE>
|
|
<DD>
|
|
Starting time, user CPU time, and system CPU time for your program and
|
|
its children.
|
|
|
|
<A NAME="IDX66"></A>
|
|
<DT><CODE>info proc id</CODE>
|
|
<DD>
|
|
Report on the process IDs related to your program: its own process ID,
|
|
the ID of its parent, the process group ID, and the session ID.
|
|
|
|
<A NAME="IDX67"></A>
|
|
<DT><CODE>info proc status</CODE>
|
|
<DD>
|
|
General information on the state of the process. If the process is
|
|
stopped, this report includes the reason for stopping, and any signal
|
|
received.
|
|
|
|
<DT><CODE>info proc all</CODE>
|
|
<DD>
|
|
Show all the above information about the process.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC25" HREF="gdb_toc.html#TOC25">Debugging programs with multiple threads</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX68"></A>
|
|
<A NAME="IDX69"></A>
|
|
<A NAME="IDX70"></A>
|
|
In some operating systems, a single program may have more than one
|
|
<STRONG>thread</STRONG> of execution. The precise semantics of threads differ from
|
|
one operating system to another, but in general the threads of a single
|
|
program are akin to multiple processes--except that they share one
|
|
address space (that is, they can all examine and modify the same
|
|
variables). On the other hand, each thread has its own registers and
|
|
execution stack, and perhaps private memory.
|
|
|
|
</P>
|
|
<P>
|
|
GDB provides these facilities for debugging multi-thread
|
|
programs:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>automatic notification of new threads
|
|
|
|
<LI><SAMP>`thread <VAR>threadno</VAR>'</SAMP>, a command to switch among threads
|
|
|
|
<LI><SAMP>`info threads'</SAMP>, a command to inquire about existing threads
|
|
|
|
<LI><SAMP>`thread apply [<VAR>threadno</VAR>] [<VAR>all</VAR>] <VAR>args</VAR>'</SAMP>,
|
|
|
|
a command to apply a command to a list of threads
|
|
<LI>thread-specific breakpoints
|
|
|
|
</UL>
|
|
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> These facilities are not yet available on every
|
|
GDB configuration where the operating system supports threads.
|
|
If your GDB does not support threads, these commands have no
|
|
effect. For example, a system without thread support shows no output
|
|
from <SAMP>`info threads'</SAMP>, and always rejects the <CODE>thread</CODE> command,
|
|
like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) info threads
|
|
(gdb) thread 1
|
|
Thread ID 1 not known. Use the "info threads" command to
|
|
see the IDs of currently known threads.
|
|
</PRE>
|
|
|
|
</BLOCKQUOTE>
|
|
|
|
<P>
|
|
<A NAME="IDX71"></A>
|
|
<A NAME="IDX72"></A>
|
|
The GDB thread debugging facility allows you to observe all
|
|
threads while your program runs--but whenever GDB takes
|
|
control, one thread in particular is always the focus of debugging.
|
|
This thread is called the <STRONG>current thread</STRONG>. Debugging commands show
|
|
program information from the perspective of the current thread.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX73"></A>
|
|
<A NAME="IDX74"></A>
|
|
Whenever GDB detects a new thread in your program, it displays
|
|
the target system's identification for the thread with a message in the
|
|
form <SAMP>`[New <VAR>systag</VAR>]'</SAMP>. <VAR>systag</VAR> is a thread identifier
|
|
whose form varies depending on the particular system. For example, on
|
|
LynxOS, you might see
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
[New process 35 thread 27]
|
|
</PRE>
|
|
|
|
<P>
|
|
when GDB notices a new thread. In contrast, on an SGI system,
|
|
the <VAR>systag</VAR> is simply something like <SAMP>`process 368'</SAMP>, with no
|
|
further qualifier.
|
|
|
|
</P>
|
|
|
|
<P>
|
|
<A NAME="IDX75"></A>
|
|
<A NAME="IDX76"></A>
|
|
For debugging purposes, GDB associates its own thread
|
|
number--always a single integer--with each thread in your program.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info threads</CODE>
|
|
<DD>
|
|
<A NAME="IDX77"></A>
|
|
|
|
Display a summary of all threads currently in your
|
|
program. GDB displays for each thread (in this order):
|
|
|
|
|
|
<OL>
|
|
<LI>the thread number assigned by GDB
|
|
|
|
<LI>the target system's thread identifier (<VAR>systag</VAR>)
|
|
|
|
<LI>the current stack frame summary for that thread
|
|
|
|
</OL>
|
|
|
|
An asterisk <SAMP>`*'</SAMP> to the left of the GDB thread number
|
|
indicates the current thread.
|
|
|
|
For example,
|
|
</DL>
|
|
|
|
|
|
<PRE>
|
|
(gdb) info threads
|
|
3 process 35 thread 27 0x34e5 in sigpause ()
|
|
2 process 35 thread 23 0x34e5 in sigpause ()
|
|
* 1 process 35 thread 13 main (argc=1, argv=0x7ffffff8)
|
|
at threadtest.c:68
|
|
</PRE>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>thread <VAR>threadno</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX78"></A>
|
|
|
|
Make thread number <VAR>threadno</VAR> the current thread. The command
|
|
argument <VAR>threadno</VAR> is the internal GDB thread number, as
|
|
shown in the first field of the <SAMP>`info threads'</SAMP> display.
|
|
GDB responds by displaying the system identifier of the thread
|
|
you selected, and its current stack frame summary:
|
|
|
|
|
|
<PRE>
|
|
(gdb) thread 2
|
|
[Switching to process 35 thread 23]
|
|
0x34e5 in sigpause ()
|
|
</PRE>
|
|
|
|
As with the <SAMP>`[New ...]'</SAMP> message, the form of the text after
|
|
<SAMP>`Switching to'</SAMP> depends on your system's conventions for identifying
|
|
threads.
|
|
|
|
<A NAME="IDX79"></A>
|
|
<DT><CODE>thread apply [<VAR>threadno</VAR>] [<VAR>all</VAR>] <VAR>args</VAR></CODE>
|
|
<DD>
|
|
The <CODE>thread apply</CODE> command allows you to apply a command to one or
|
|
more threads. Specify the numbers of the threads that you want affected
|
|
with the command argument <VAR>threadno</VAR>. <VAR>threadno</VAR> is the internal
|
|
GDB thread number, as shown in the first field of the <SAMP>`info
|
|
threads'</SAMP> display. To apply a command to all threads, use
|
|
<CODE>thread apply all</CODE> <VAR>args</VAR>.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX80"></A>
|
|
<A NAME="IDX81"></A>
|
|
<A NAME="IDX82"></A>
|
|
Whenever GDB stops your program, due to a breakpoint or a
|
|
signal, it automatically selects the thread where that breakpoint or
|
|
signal happened. GDB alerts you to the context switch with a
|
|
message of the form <SAMP>`[Switching to <VAR>systag</VAR>]'</SAMP> to identify the
|
|
thread.
|
|
|
|
</P>
|
|
<P>
|
|
See section <A HREF="gdb.html#SEC39">Stopping and starting multi-thread programs</A>, for
|
|
more information about how GDB behaves when you stop and start
|
|
programs with multiple threads.
|
|
|
|
</P>
|
|
<P>
|
|
See section <A HREF="gdb.html#SEC30">Setting watchpoints</A>, for information about
|
|
watchpoints in programs with multiple threads.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC26" HREF="gdb_toc.html#TOC26">Debugging programs with multiple processes</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX83"></A>
|
|
<A NAME="IDX84"></A>
|
|
<A NAME="IDX85"></A>
|
|
GDB has no special support for debugging programs which create
|
|
additional processes using the <CODE>fork</CODE> function. When a program
|
|
forks, GDB will continue to debug the parent process and the
|
|
child process will run unimpeded. If you have set a breakpoint in any
|
|
code which the child then executes, the child will get a <CODE>SIGTRAP</CODE>
|
|
signal which (unless it catches the signal) will cause it to terminate.
|
|
|
|
</P>
|
|
<P>
|
|
However, if you want to debug the child process there is a workaround
|
|
which isn't too painful. Put a call to <CODE>sleep</CODE> in the code which
|
|
the child process executes after the fork. It may be useful to sleep
|
|
only if a certain environment variable is set, or a certain file exists,
|
|
so that the delay need not occur when you don't want to run GDB
|
|
on the child. While the child is sleeping, use the <CODE>ps</CODE> program to
|
|
get its process ID. Then tell GDB (a new invocation of
|
|
GDB if you are also debugging the parent process) to attach to
|
|
the child process (see section <A HREF="gdb.html#SEC22">Debugging an already-running process</A>). From that point on you can debug
|
|
the child process just like any other process which you attached to.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC27" HREF="gdb_toc.html#TOC27">Stopping and Continuing</A></H1>
|
|
|
|
<P>
|
|
The principal purposes of using a debugger are so that you can stop your
|
|
program before it terminates; or so that, if your program runs into
|
|
trouble, you can investigate and find out why.
|
|
|
|
</P>
|
|
<P>
|
|
Inside GDB, your program may stop for any of several reasons, such
|
|
as
|
|
a signal,
|
|
a breakpoint, or reaching a new line after a GDB
|
|
command such as <CODE>step</CODE>. You may then examine and change
|
|
variables, set new breakpoints or remove old ones, and then continue
|
|
execution. Usually, the messages shown by GDB provide ample
|
|
explanation of the status of your program--but you can also explicitly
|
|
request this information at any time.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info program</CODE>
|
|
<DD>
|
|
<A NAME="IDX86"></A>
|
|
|
|
Display information about the status of your program: whether it is
|
|
running or not,
|
|
what process it is,
|
|
and why it stopped.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC28" HREF="gdb_toc.html#TOC28">Breakpoints, watchpoints, and exceptions</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX87"></A>
|
|
A <STRONG>breakpoint</STRONG> makes your program stop whenever a certain point in
|
|
the program is reached. For each breakpoint, you can add
|
|
conditions to control in finer detail whether your program stops.
|
|
You can set breakpoints with the <CODE>break</CODE> command and its variants
|
|
(see section <A HREF="gdb.html#SEC29">Setting breakpoints</A>), to specify the place where
|
|
your program should stop by line number, function name or exact address
|
|
in the program.
|
|
In languages with exception handling (such as GNU C++), you can also set
|
|
breakpoints where an exception is raised (see section <A HREF="gdb.html#SEC31">Breakpoints and exceptions</A>).
|
|
|
|
</P>
|
|
<P>
|
|
In SunOS 4.x, SVR4, and Alpha OSF/1 configurations, you can now set
|
|
breakpoints in shared libraries before the executable is run.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX88"></A>
|
|
<A NAME="IDX89"></A>
|
|
<A NAME="IDX90"></A>
|
|
<A NAME="IDX91"></A>
|
|
A <STRONG>watchpoint</STRONG> is a special breakpoint that stops your program
|
|
when the value of an expression changes. You must use a different
|
|
command to set watchpoints (see section <A HREF="gdb.html#SEC30">Setting watchpoints</A>), but aside from that, you can manage a watchpoint like
|
|
any other breakpoint: you enable, disable, and delete both breakpoints
|
|
and watchpoints using the same commands.
|
|
|
|
</P>
|
|
<P>
|
|
You can arrange to have values from your program displayed automatically
|
|
whenever GDB stops at a breakpoint. See section <A HREF="gdb.html#SEC57">Automatic display</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX92"></A>
|
|
<A NAME="IDX93"></A>
|
|
GDB assigns a number to each breakpoint or watchpoint when you
|
|
create it; these numbers are successive integers starting with one. In
|
|
many of the commands for controlling various features of breakpoints you
|
|
use the breakpoint number to say which breakpoint you want to change.
|
|
Each breakpoint may be <STRONG>enabled</STRONG> or <STRONG>disabled</STRONG>; if disabled, it has
|
|
no effect on your program until you enable it again.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC29" HREF="gdb_toc.html#TOC29">Setting breakpoints</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX94"></A>
|
|
<A NAME="IDX95"></A>
|
|
<A NAME="IDX96"></A>
|
|
<A NAME="IDX97"></A>
|
|
Breakpoints are set with the <CODE>break</CODE> command (abbreviated
|
|
<CODE>b</CODE>). The debugger convenience variable <SAMP>`$bpnum'</SAMP> records the
|
|
number of the breakpoints you've set most recently; see section <A HREF="gdb.html#SEC60">Convenience variables</A>, for a discussion of what you can do with
|
|
convenience variables.
|
|
|
|
</P>
|
|
<P>
|
|
You have several ways to say where the breakpoint should go.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>break <VAR>function</VAR></CODE>
|
|
<DD>
|
|
Set a breakpoint at entry to function <VAR>function</VAR>.
|
|
When using source languages that permit overloading of symbols, such as
|
|
C++, <VAR>function</VAR> may refer to more than one possible place to break.
|
|
See section <A HREF="gdb.html#SEC36">Breakpoint menus</A>, for a discussion of that situation.
|
|
|
|
<DT><CODE>break +<VAR>offset</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>break -<VAR>offset</VAR></CODE>
|
|
<DD>
|
|
Set a breakpoint some number of lines forward or back from the position
|
|
at which execution stopped in the currently selected frame.
|
|
|
|
<DT><CODE>break <VAR>linenum</VAR></CODE>
|
|
<DD>
|
|
Set a breakpoint at line <VAR>linenum</VAR> in the current source file.
|
|
That file is the last file whose source text was printed. This
|
|
breakpoint stops your program just before it executes any of the
|
|
code on that line.
|
|
|
|
<DT><CODE>break <VAR>filename</VAR>:<VAR>linenum</VAR></CODE>
|
|
<DD>
|
|
Set a breakpoint at line <VAR>linenum</VAR> in source file <VAR>filename</VAR>.
|
|
|
|
<DT><CODE>break <VAR>filename</VAR>:<VAR>function</VAR></CODE>
|
|
<DD>
|
|
Set a breakpoint at entry to function <VAR>function</VAR> found in file
|
|
<VAR>filename</VAR>. Specifying a file name as well as a function name is
|
|
superfluous except when multiple files contain similarly named
|
|
functions.
|
|
|
|
<DT><CODE>break *<VAR>address</VAR></CODE>
|
|
<DD>
|
|
Set a breakpoint at address <VAR>address</VAR>. You can use this to set
|
|
breakpoints in parts of your program which do not have debugging
|
|
information or source files.
|
|
|
|
<DT><CODE>break</CODE>
|
|
<DD>
|
|
When called without any arguments, <CODE>break</CODE> sets a breakpoint at
|
|
the next instruction to be executed in the selected stack frame
|
|
(see section <A HREF="gdb.html#SEC40">Examining the Stack</A>). In any selected frame but the
|
|
innermost, this makes your program stop as soon as control
|
|
returns to that frame. This is similar to the effect of a
|
|
<CODE>finish</CODE> command in the frame inside the selected frame--except
|
|
that <CODE>finish</CODE> does not leave an active breakpoint. If you use
|
|
<CODE>break</CODE> without an argument in the innermost frame, GDB stops
|
|
the next time it reaches the current location; this may be useful
|
|
inside loops.
|
|
|
|
GDB normally ignores breakpoints when it resumes execution, until at
|
|
least one instruction has been executed. If it did not do this, you
|
|
would be unable to proceed past a breakpoint without first disabling the
|
|
breakpoint. This rule applies whether or not the breakpoint already
|
|
existed when your program stopped.
|
|
|
|
<DT><CODE>break ... if <VAR>cond</VAR></CODE>
|
|
<DD>
|
|
Set a breakpoint with condition <VAR>cond</VAR>; evaluate the expression
|
|
<VAR>cond</VAR> each time the breakpoint is reached, and stop only if the
|
|
value is nonzero--that is, if <VAR>cond</VAR> evaluates as true.
|
|
<SAMP>`...'</SAMP> stands for one of the possible arguments described
|
|
above (or no argument) specifying where to break. See section <A HREF="gdb.html#SEC34">Break conditions</A>, for more information on breakpoint conditions.
|
|
|
|
<A NAME="IDX98"></A>
|
|
<DT><CODE>tbreak <VAR>args</VAR></CODE>
|
|
<DD>
|
|
Set a breakpoint enabled only for one stop. <VAR>args</VAR> are the
|
|
same as for the <CODE>break</CODE> command, and the breakpoint is set in the same
|
|
way, but the breakpoint is automatically deleted after the first time your
|
|
program stops there. See section <A HREF="gdb.html#SEC33">Disabling breakpoints</A>.
|
|
|
|
<A NAME="IDX99"></A>
|
|
<DT><CODE>hbreak <VAR>args</VAR></CODE>
|
|
<DD>
|
|
Set a hardware-assisted breakpoint. <VAR>args</VAR> are the same as for the
|
|
<CODE>break</CODE> command and the breakpoint is set in the same way, but the
|
|
breakpoint requires hardware support and some target hardware may not
|
|
have this support. The main purpose of this is EPROM/ROM code
|
|
debugging, so you can set a breakpoint at an instruction without
|
|
changing the instruction. This can be used with the new trap-generation
|
|
provided by SPARClite DSU. DSU will generate traps when a program accesses
|
|
some date or instruction address that is assigned to the debug registers.
|
|
However the hardware breakpoint registers can only take two data breakpoints,
|
|
and GDB will reject this command if more than two are used.
|
|
Delete or disable usused hardware breakpoints before setting
|
|
new ones. See section <A HREF="gdb.html#SEC34">Break conditions</A>.
|
|
|
|
<A NAME="IDX100"></A>
|
|
<DT><CODE>thbreak <VAR>args</VAR></CODE>
|
|
<DD>
|
|
Set a hardware-assisted breakpoint enabled only for one stop. <VAR>args</VAR>
|
|
are the same as for the <CODE>hbreak</CODE> command and the breakpoint is set in
|
|
the same way. However, like the <CODE>tbreak</CODE> command,
|
|
the breakpoint is automatically deleted after the
|
|
first time your program stops there. Also, like the <CODE>hbreak</CODE>
|
|
command, the breakpoint requires hardware support and some target hardware
|
|
may not have this support. See section <A HREF="gdb.html#SEC33">Disabling breakpoints</A>.
|
|
Also See section <A HREF="gdb.html#SEC34">Break conditions</A>.
|
|
|
|
<A NAME="IDX101"></A>
|
|
<A NAME="IDX102"></A>
|
|
<DT><CODE>rbreak <VAR>regex</VAR></CODE>
|
|
<DD>
|
|
Set breakpoints on all functions matching the regular expression
|
|
<VAR>regex</VAR>. This command
|
|
sets an unconditional breakpoint on all matches, printing a list of all
|
|
breakpoints it set. Once these breakpoints are set, they are treated
|
|
just like the breakpoints set with the <CODE>break</CODE> command. You can
|
|
delete them, disable them, or make them conditional the same way as any
|
|
other breakpoint.
|
|
|
|
When debugging C++ programs, <CODE>rbreak</CODE> is useful for setting
|
|
breakpoints on overloaded functions that are not members of any special
|
|
classes.
|
|
|
|
<A NAME="IDX103"></A>
|
|
<A NAME="IDX104"></A>
|
|
<DT><CODE>info breakpoints [<VAR>n</VAR>]</CODE>
|
|
<DD>
|
|
<DT><CODE>info break [<VAR>n</VAR>]</CODE>
|
|
<DD>
|
|
<DT><CODE>info watchpoints [<VAR>n</VAR>]</CODE>
|
|
<DD>
|
|
Print a table of all breakpoints and watchpoints set and not
|
|
deleted, with the following columns for each breakpoint:
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><EM>Breakpoint Numbers</EM>
|
|
<DD>
|
|
<DT><EM>Type</EM>
|
|
<DD>
|
|
Breakpoint or watchpoint.
|
|
<DT><EM>Disposition</EM>
|
|
<DD>
|
|
Whether the breakpoint is marked to be disabled or deleted when hit.
|
|
<DT><EM>Enabled or Disabled</EM>
|
|
<DD>
|
|
Enabled breakpoints are marked with <SAMP>`y'</SAMP>. <SAMP>`n'</SAMP> marks breakpoints
|
|
that are not enabled.
|
|
<DT><EM>Address</EM>
|
|
<DD>
|
|
Where the breakpoint is in your program, as a memory address
|
|
<DT><EM>What</EM>
|
|
<DD>
|
|
Where the breakpoint is in the source for your program, as a file and
|
|
line number.
|
|
</DL>
|
|
|
|
If a breakpoint is conditional, <CODE>info break</CODE> shows the condition on
|
|
the line following the affected breakpoint; breakpoint commands, if any,
|
|
are listed after that.
|
|
|
|
<CODE>info break</CODE> with a breakpoint
|
|
number <VAR>n</VAR> as argument lists only that breakpoint. The
|
|
convenience variable <CODE>$_</CODE> and the default examining-address for
|
|
the <CODE>x</CODE> command are set to the address of the last breakpoint
|
|
listed (see section <A HREF="gdb.html#SEC56">Examining memory</A>).
|
|
|
|
<CODE>info break</CODE> now displays a count of the number of times the
|
|
breakpoint has been hit. This is especially useful in conjunction with
|
|
the <CODE>ignore</CODE> command. You can ignore a large number of breakpoint
|
|
hits, look at the breakpoint info to see how many times the
|
|
breakpoint was hit, and then run again, ignoring one less than that
|
|
number. This will get you quickly to the last hit of that breakpoint.
|
|
</DL>
|
|
|
|
<P>
|
|
GDB allows you to set any number of breakpoints at the same place in
|
|
your program. There is nothing silly or meaningless about this. When
|
|
the breakpoints are conditional, this is even useful
|
|
(see section <A HREF="gdb.html#SEC34">Break conditions</A>).
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX105"></A>
|
|
<A NAME="IDX106"></A>
|
|
GDB itself sometimes sets breakpoints in your program for special
|
|
purposes, such as proper handling of <CODE>longjmp</CODE> (in C programs).
|
|
These internal breakpoints are assigned negative numbers, starting with
|
|
<CODE>-1</CODE>; <SAMP>`info breakpoints'</SAMP> does not display them.
|
|
|
|
</P>
|
|
<P>
|
|
You can see these breakpoints with the GDB maintenance command
|
|
<SAMP>`maint info breakpoints'</SAMP>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>maint info breakpoints</CODE>
|
|
<DD>
|
|
<A NAME="IDX107"></A>
|
|
|
|
Using the same format as <SAMP>`info breakpoints'</SAMP>, display both the
|
|
breakpoints you've set explicitly, and those GDB is using for
|
|
internal purposes. Internal breakpoints are shown with negative
|
|
breakpoint numbers. The type column identifies what kind of breakpoint
|
|
is shown:
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>breakpoint</CODE>
|
|
<DD>
|
|
Normal, explicitly set breakpoint.
|
|
|
|
<DT><CODE>watchpoint</CODE>
|
|
<DD>
|
|
Normal, explicitly set watchpoint.
|
|
|
|
<DT><CODE>longjmp</CODE>
|
|
<DD>
|
|
Internal breakpoint, used to handle correctly stepping through
|
|
<CODE>longjmp</CODE> calls.
|
|
|
|
<DT><CODE>longjmp resume</CODE>
|
|
<DD>
|
|
Internal breakpoint at the target of a <CODE>longjmp</CODE>.
|
|
|
|
<DT><CODE>until</CODE>
|
|
<DD>
|
|
Temporary internal breakpoint used by the GDB <CODE>until</CODE> command.
|
|
|
|
<DT><CODE>finish</CODE>
|
|
<DD>
|
|
Temporary internal breakpoint used by the GDB <CODE>finish</CODE> command.
|
|
</DL>
|
|
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC30" HREF="gdb_toc.html#TOC30">Setting watchpoints</A></H3>
|
|
<P>
|
|
<A NAME="IDX108"></A>
|
|
|
|
</P>
|
|
<P>
|
|
You can use a watchpoint to stop execution whenever the value of an
|
|
expression changes, without having to predict a particular place
|
|
where this may happen.
|
|
|
|
</P>
|
|
<P>
|
|
Watchpoints currently execute two orders of magnitude more slowly than
|
|
other breakpoints, but this can be well worth it to catch errors where
|
|
you have no clue what part of your program is the culprit.
|
|
|
|
</P>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>watch <VAR>expr</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX109"></A>
|
|
|
|
Set a watchpoint for an expression. GDB will break when <VAR>expr</VAR>
|
|
is written into by the program and its value changes.
|
|
This can be used with the new trap-generation provided by
|
|
SPARClite DSU. DSU will generate traps when a program accesses
|
|
some date or instruction address that is assigned to the debug registers.
|
|
For the data addresses, DSU facilitates the <CODE>watch</CODE> command.
|
|
However the hardware breakpoint registers can only take two data watchpoints,
|
|
and both watchpoints must be the same kind. For example, you can set two
|
|
watchpoints with <CODE>watch</CODE> commands, two with <CODE>rwatch</CODE>
|
|
commands, <STRONG>or</STRONG> two with <CODE>awatch</CODE> commands, but you cannot set one
|
|
watchpoint with one command and the other with a different command.
|
|
will reject the command if you try to mix watchpoints.
|
|
Delete or disable unused watchpoint commands before setting new ones.
|
|
|
|
<A NAME="IDX110"></A>
|
|
<DT><CODE>rwatch <VAR>expr</VAR></CODE>
|
|
<DD>
|
|
Set a watchpoint that will break when watch <VAR>args</VAR> is read by the program.
|
|
If you use both watchpoints, both must be set with the <CODE>rwatch</CODE>
|
|
command.
|
|
|
|
<A NAME="IDX111"></A>
|
|
<DT><CODE>awatch <VAR>expr</VAR></CODE>
|
|
<DD>
|
|
Set a watchpoint that will break when <VAR>args</VAR> is read and written into
|
|
by the program. If you use both watchpoints, both must be set with the
|
|
<CODE>awatch</CODE> command.
|
|
|
|
<A NAME="IDX112"></A>
|
|
<DT><CODE>info watchpoints</CODE>
|
|
<DD>
|
|
This command prints a list of watchpoints and breakpoints; it is the
|
|
same as <CODE>info break</CODE>.
|
|
</DL>
|
|
|
|
|
|
<BLOCKQUOTE>
|
|
<A NAME="IDX113"></A>
|
|
<A NAME="IDX114"></A>
|
|
<P>
|
|
<EM>Warning:</EM> in multi-thread programs, watchpoints have only limited
|
|
usefulness. With the current watchpoint implementation, GDB
|
|
can only watch the value of an expression <EM>in a single thread</EM>. If
|
|
you are confident that the expression can only change due to the current
|
|
thread's activity (and if you are also confident that no other thread
|
|
can become current), then you can use watchpoints as usual. However,
|
|
GDB may not notice when a non-current thread's activity changes
|
|
the expression.
|
|
</BLOCKQUOTE>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC31" HREF="gdb_toc.html#TOC31">Breakpoints and exceptions</A></H3>
|
|
<P>
|
|
<A NAME="IDX115"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Some languages, such as GNU C++, implement exception handling. You can
|
|
use GDB to examine what caused your program to raise an exception,
|
|
and to list the exceptions your program is prepared to handle at a
|
|
given point in time.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>catch <VAR>exceptions</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX116"></A>
|
|
|
|
You can set breakpoints at active exception handlers by using the
|
|
<CODE>catch</CODE> command. <VAR>exceptions</VAR> is a list of names of exceptions
|
|
to catch.
|
|
</DL>
|
|
|
|
<P>
|
|
You can use <CODE>info catch</CODE> to list active exception handlers.
|
|
See section <A HREF="gdb.html#SEC44">Information about a frame</A>.
|
|
|
|
</P>
|
|
<P>
|
|
There are currently some limitations to exception handling in GDB:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
If you call a function interactively, GDB normally returns
|
|
control to you when the function has finished executing. If the call
|
|
raises an exception, however, the call may bypass the mechanism that
|
|
returns control to you and cause your program to simply continue
|
|
running until it hits a breakpoint, catches a signal that GDB is
|
|
listening for, or exits.
|
|
|
|
<LI>
|
|
|
|
You cannot raise an exception interactively.
|
|
|
|
<LI>
|
|
|
|
You cannot install an exception handler interactively.
|
|
</UL>
|
|
|
|
<P>
|
|
<A NAME="IDX117"></A>
|
|
Sometimes <CODE>catch</CODE> is not the best way to debug exception handling:
|
|
if you need to know exactly where an exception is raised, it is better to
|
|
stop <EM>before</EM> the exception handler is called, since that way you
|
|
can see the stack before any unwinding takes place. If you set a
|
|
breakpoint in an exception handler instead, it may not be easy to find
|
|
out where the exception was raised.
|
|
|
|
</P>
|
|
<P>
|
|
To stop just before an exception handler is called, you need some
|
|
knowledge of the implementation. In the case of GNU C++, exceptions are
|
|
raised by calling a library function named <CODE>__raise_exception</CODE>
|
|
which has the following ANSI C interface:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
/* <VAR>addr</VAR> is where the exception identifier is stored.
|
|
ID is the exception identifier. */
|
|
void __raise_exception (void **<VAR>addr</VAR>, void *<VAR>id</VAR>);
|
|
</PRE>
|
|
|
|
<P>
|
|
To make the debugger catch all exceptions before any stack
|
|
unwinding takes place, set a breakpoint on <CODE>__raise_exception</CODE>
|
|
(see section <A HREF="gdb.html#SEC28">Breakpoints, watchpoints, and exceptions</A>).
|
|
|
|
</P>
|
|
<P>
|
|
With a conditional breakpoint (see section <A HREF="gdb.html#SEC34">Break conditions</A>)
|
|
that depends on the value of <VAR>id</VAR>, you can stop your program when
|
|
a specific exception is raised. You can use multiple conditional
|
|
breakpoints to stop your program when any of a number of exceptions are
|
|
raised.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC32" HREF="gdb_toc.html#TOC32">Deleting breakpoints</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX118"></A>
|
|
<A NAME="IDX119"></A>
|
|
It is often necessary to eliminate a breakpoint or watchpoint once it
|
|
has done its job and you no longer want your program to stop there. This
|
|
is called <STRONG>deleting</STRONG> the breakpoint. A breakpoint that has been
|
|
deleted no longer exists; it is forgotten.
|
|
|
|
</P>
|
|
<P>
|
|
With the <CODE>clear</CODE> command you can delete breakpoints according to
|
|
where they are in your program. With the <CODE>delete</CODE> command you can
|
|
delete individual breakpoints or watchpoints by specifying their
|
|
breakpoint numbers.
|
|
|
|
</P>
|
|
<P>
|
|
It is not necessary to delete a breakpoint to proceed past it. GDB
|
|
automatically ignores breakpoints on the first instruction to be executed
|
|
when you continue execution without changing the execution address.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>clear</CODE>
|
|
<DD>
|
|
<A NAME="IDX120"></A>
|
|
Delete any breakpoints at the next instruction to be executed in the
|
|
selected stack frame (see section <A HREF="gdb.html#SEC43">Selecting a frame</A>). When
|
|
the innermost frame is selected, this is a good way to delete a
|
|
breakpoint where your program just stopped.
|
|
|
|
<DT><CODE>clear <VAR>function</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>clear <VAR>filename</VAR>:<VAR>function</VAR></CODE>
|
|
<DD>
|
|
Delete any breakpoints set at entry to the function <VAR>function</VAR>.
|
|
|
|
<DT><CODE>clear <VAR>linenum</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>clear <VAR>filename</VAR>:<VAR>linenum</VAR></CODE>
|
|
<DD>
|
|
Delete any breakpoints set at or within the code of the specified line.
|
|
|
|
<A NAME="IDX121"></A>
|
|
<A NAME="IDX122"></A>
|
|
<A NAME="IDX123"></A>
|
|
<DT><CODE>delete [breakpoints] [<VAR>bnums</VAR>...]</CODE>
|
|
<DD>
|
|
Delete the breakpoints or watchpoints of the numbers specified as
|
|
arguments. If no argument is specified, delete all breakpoints (GDB
|
|
asks confirmation, unless you have <CODE>set confirm off</CODE>). You
|
|
can abbreviate this command as <CODE>d</CODE>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC33" HREF="gdb_toc.html#TOC33">Disabling breakpoints</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX124"></A>
|
|
<A NAME="IDX125"></A>
|
|
Rather than deleting a breakpoint or watchpoint, you might prefer to
|
|
<STRONG>disable</STRONG> it. This makes the breakpoint inoperative as if it had
|
|
been deleted, but remembers the information on the breakpoint so that
|
|
you can <STRONG>enable</STRONG> it again later.
|
|
|
|
</P>
|
|
<P>
|
|
You disable and enable breakpoints and watchpoints with the
|
|
<CODE>enable</CODE> and <CODE>disable</CODE> commands, optionally specifying one or
|
|
more breakpoint numbers as arguments. Use <CODE>info break</CODE> or
|
|
<CODE>info watch</CODE> to print a list of breakpoints or watchpoints if you
|
|
do not know which numbers to use.
|
|
|
|
</P>
|
|
<P>
|
|
A breakpoint or watchpoint can have any of four different states of
|
|
enablement:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Enabled. The breakpoint stops your program. A breakpoint set
|
|
with the <CODE>break</CODE> command starts out in this state.
|
|
<LI>
|
|
|
|
Disabled. The breakpoint has no effect on your program.
|
|
<LI>
|
|
|
|
Enabled once. The breakpoint stops your program, but then becomes
|
|
disabled. A breakpoint set with the <CODE>tbreak</CODE> command starts out in
|
|
this state.
|
|
<LI>
|
|
|
|
Enabled for deletion. The breakpoint stops your program, but
|
|
immediately after it does so it is deleted permanently.
|
|
</UL>
|
|
|
|
<P>
|
|
You can use the following commands to enable or disable breakpoints and
|
|
watchpoints:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>disable [breakpoints] [<VAR>bnums</VAR>...]</CODE>
|
|
<DD>
|
|
<A NAME="IDX126"></A>
|
|
<A NAME="IDX127"></A>
|
|
<A NAME="IDX128"></A>
|
|
|
|
Disable the specified breakpoints--or all breakpoints, if none are
|
|
listed. A disabled breakpoint has no effect but is not forgotten. All
|
|
options such as ignore-counts, conditions and commands are remembered in
|
|
case the breakpoint is enabled again later. You may abbreviate
|
|
<CODE>disable</CODE> as <CODE>dis</CODE>.
|
|
|
|
<A NAME="IDX129"></A>
|
|
<A NAME="IDX130"></A>
|
|
<DT><CODE>enable [breakpoints] [<VAR>bnums</VAR>...]</CODE>
|
|
<DD>
|
|
Enable the specified breakpoints (or all defined breakpoints). They
|
|
become effective once again in stopping your program.
|
|
|
|
<DT><CODE>enable [breakpoints] once <VAR>bnums</VAR>...</CODE>
|
|
<DD>
|
|
Enable the specified breakpoints temporarily. GDB disables any
|
|
of these breakpoints immediately after stopping your program.
|
|
|
|
<DT><CODE>enable [breakpoints] delete <VAR>bnums</VAR>...</CODE>
|
|
<DD>
|
|
Enable the specified breakpoints to work once, then die. GDB
|
|
deletes any of these breakpoints as soon as your program stops there.
|
|
</DL>
|
|
|
|
<P>
|
|
Except for a breakpoint set with <CODE>tbreak</CODE> (see section <A HREF="gdb.html#SEC29">Setting breakpoints</A>), breakpoints that you set are initially enabled;
|
|
subsequently, they become disabled or enabled only when you use one of
|
|
the commands above. (The command <CODE>until</CODE> can set and delete a
|
|
breakpoint of its own, but it does not change the state of your other
|
|
breakpoints; see section <A HREF="gdb.html#SEC37">Continuing and stepping</A>.)
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC34" HREF="gdb_toc.html#TOC34">Break conditions</A></H3>
|
|
<P>
|
|
<A NAME="IDX131"></A>
|
|
<A NAME="IDX132"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The simplest sort of breakpoint breaks every time your program reaches a
|
|
specified place. You can also specify a <STRONG>condition</STRONG> for a
|
|
breakpoint. A condition is just a Boolean expression in your
|
|
programming language (see section <A HREF="gdb.html#SEC52">Expressions</A>). A breakpoint with
|
|
a condition evaluates the expression each time your program reaches it,
|
|
and your program stops only if the condition is <EM>true</EM>.
|
|
|
|
</P>
|
|
<P>
|
|
This is the converse of using assertions for program validation; in that
|
|
situation, you want to stop when the assertion is violated--that is,
|
|
when the condition is false. In C, if you want to test an assertion expressed
|
|
by the condition <VAR>assert</VAR>, you should set the condition
|
|
<SAMP>`! <VAR>assert</VAR>'</SAMP> on the appropriate breakpoint.
|
|
|
|
</P>
|
|
<P>
|
|
Conditions are also accepted for watchpoints; you may not need them,
|
|
since a watchpoint is inspecting the value of an expression anyhow--but
|
|
it might be simpler, say, to just set a watchpoint on a variable name,
|
|
and specify a condition that tests whether the new value is an interesting
|
|
one.
|
|
|
|
</P>
|
|
<P>
|
|
Break conditions can have side effects, and may even call functions in
|
|
your program. This can be useful, for example, to activate functions
|
|
that log program progress, or to use your own print functions to
|
|
format special data structures. The effects are completely predictable
|
|
unless there is another enabled breakpoint at the same address. (In
|
|
that case, GDB might see the other breakpoint first and stop your
|
|
program without checking the condition of this one.) Note that
|
|
breakpoint commands are usually more convenient and flexible for the
|
|
purpose of performing side effects when a breakpoint is reached
|
|
(see section <A HREF="gdb.html#SEC35">Breakpoint command lists</A>).
|
|
|
|
</P>
|
|
<P>
|
|
Break conditions can be specified when a breakpoint is set, by using
|
|
<SAMP>`if'</SAMP> in the arguments to the <CODE>break</CODE> command. See section <A HREF="gdb.html#SEC29">Setting breakpoints</A>. They can also be changed at any time
|
|
with the <CODE>condition</CODE> command. The <CODE>watch</CODE> command does not
|
|
recognize the <CODE>if</CODE> keyword; <CODE>condition</CODE> is the only way to
|
|
impose a further condition on a watchpoint.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>condition <VAR>bnum</VAR> <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX133"></A>
|
|
|
|
Specify <VAR>expression</VAR> as the break condition for breakpoint or
|
|
watchpoint number <VAR>bnum</VAR>. After you set a condition, breakpoint
|
|
<VAR>bnum</VAR> stops your program only if the value of <VAR>expression</VAR> is
|
|
true (nonzero, in C). When you use <CODE>condition</CODE>, GDB
|
|
checks <VAR>expression</VAR> immediately for syntactic correctness, and to
|
|
determine whether symbols in it have referents in the context of your
|
|
breakpoint.
|
|
GDB does
|
|
not actually evaluate <VAR>expression</VAR> at the time the <CODE>condition</CODE>
|
|
command is given, however. See section <A HREF="gdb.html#SEC52">Expressions</A>.
|
|
|
|
<DT><CODE>condition <VAR>bnum</VAR></CODE>
|
|
<DD>
|
|
Remove the condition from breakpoint number <VAR>bnum</VAR>. It becomes
|
|
an ordinary unconditional breakpoint.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX134"></A>
|
|
A special case of a breakpoint condition is to stop only when the
|
|
breakpoint has been reached a certain number of times. This is so
|
|
useful that there is a special way to do it, using the <STRONG>ignore
|
|
count</STRONG> of the breakpoint. Every breakpoint has an ignore count, which
|
|
is an integer. Most of the time, the ignore count is zero, and
|
|
therefore has no effect. But if your program reaches a breakpoint whose
|
|
ignore count is positive, then instead of stopping, it just decrements
|
|
the ignore count by one and continues. As a result, if the ignore count
|
|
value is <VAR>n</VAR>, the breakpoint does not stop the next <VAR>n</VAR> times
|
|
your program reaches it.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>ignore <VAR>bnum</VAR> <VAR>count</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX135"></A>
|
|
|
|
Set the ignore count of breakpoint number <VAR>bnum</VAR> to <VAR>count</VAR>.
|
|
The next <VAR>count</VAR> times the breakpoint is reached, your program's
|
|
execution does not stop; other than to decrement the ignore count, GDB
|
|
takes no action.
|
|
|
|
To make the breakpoint stop the next time it is reached, specify
|
|
a count of zero.
|
|
|
|
When you use <CODE>continue</CODE> to resume execution of your program from a
|
|
breakpoint, you can specify an ignore count directly as an argument to
|
|
<CODE>continue</CODE>, rather than using <CODE>ignore</CODE>. See section <A HREF="gdb.html#SEC37">Continuing and stepping</A>.
|
|
|
|
If a breakpoint has a positive ignore count and a condition, the
|
|
condition is not checked. Once the ignore count reaches zero,
|
|
GDB resumes checking the condition.
|
|
|
|
You could achieve the effect of the ignore count with a condition such
|
|
as <SAMP>`$foo-- <= 0'</SAMP> using a debugger convenience variable that
|
|
is decremented each time. See section <A HREF="gdb.html#SEC60">Convenience variables</A>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC35" HREF="gdb_toc.html#TOC35">Breakpoint command lists</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX136"></A>
|
|
You can give any breakpoint (or watchpoint) a series of commands to
|
|
execute when your program stops due to that breakpoint. For example, you
|
|
might want to print the values of certain expressions, or enable other
|
|
breakpoints.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>commands [<VAR>bnum</VAR>]</CODE>
|
|
<DD>
|
|
<A NAME="IDX137"></A>
|
|
<A NAME="IDX138"></A>
|
|
|
|
<DT><CODE>... <VAR>command-list</VAR> ...</CODE>
|
|
<DD>
|
|
<DT><CODE>end</CODE>
|
|
<DD>
|
|
Specify a list of commands for breakpoint number <VAR>bnum</VAR>. The commands
|
|
themselves appear on the following lines. Type a line containing just
|
|
<CODE>end</CODE> to terminate the commands.
|
|
|
|
To remove all commands from a breakpoint, type <CODE>commands</CODE> and
|
|
follow it immediately with <CODE>end</CODE>; that is, give no commands.
|
|
|
|
With no <VAR>bnum</VAR> argument, <CODE>commands</CODE> refers to the last
|
|
breakpoint or watchpoint set (not to the breakpoint most recently
|
|
encountered).
|
|
</DL>
|
|
|
|
<P>
|
|
Pressing <KBD>RET</KBD> as a means of repeating the last GDB command is
|
|
disabled within a <VAR>command-list</VAR>.
|
|
|
|
</P>
|
|
<P>
|
|
You can use breakpoint commands to start your program up again. Simply
|
|
use the <CODE>continue</CODE> command, or <CODE>step</CODE>, or any other command
|
|
that resumes execution.
|
|
|
|
</P>
|
|
<P>
|
|
Any other commands in the command list, after a command that resumes
|
|
execution, are ignored. This is because any time you resume execution
|
|
(even with a simple <CODE>next</CODE> or <CODE>step</CODE>), you may encounter
|
|
another breakpoint--which could have its own command list, leading to
|
|
ambiguities about which list to execute.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX139"></A>
|
|
If the first command you specify in a command list is <CODE>silent</CODE>, the
|
|
usual message about stopping at a breakpoint is not printed. This may
|
|
be desirable for breakpoints that are to print a specific message and
|
|
then continue. If none of the remaining commands print anything, you
|
|
see no sign that the breakpoint was reached. <CODE>silent</CODE> is
|
|
meaningful only at the beginning of a breakpoint command list.
|
|
|
|
</P>
|
|
<P>
|
|
The commands <CODE>echo</CODE>, <CODE>output</CODE>, and <CODE>printf</CODE> allow you to
|
|
print precisely controlled output, and are often useful in silent
|
|
breakpoints. See section <A HREF="gdb.html#SEC149">Commands for controlled output</A>.
|
|
|
|
</P>
|
|
<P>
|
|
For example, here is how you could use breakpoint commands to print the
|
|
value of <CODE>x</CODE> at entry to <CODE>foo</CODE> whenever <CODE>x</CODE> is positive.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
break foo if x>0
|
|
commands
|
|
silent
|
|
printf "x is %d\n",x
|
|
cont
|
|
end
|
|
</PRE>
|
|
|
|
<P>
|
|
One application for breakpoint commands is to compensate for one bug so
|
|
you can test for another. Put a breakpoint just after the erroneous line
|
|
of code, give it a condition to detect the case in which something
|
|
erroneous has been done, and give it commands to assign correct values
|
|
to any variables that need them. End with the <CODE>continue</CODE> command
|
|
so that your program does not stop, and start with the <CODE>silent</CODE>
|
|
command so that no output is produced. Here is an example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
break 403
|
|
commands
|
|
silent
|
|
set x = y + 4
|
|
cont
|
|
end
|
|
</PRE>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC36" HREF="gdb_toc.html#TOC36">Breakpoint menus</A></H3>
|
|
<P>
|
|
<A NAME="IDX140"></A>
|
|
<A NAME="IDX141"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Some programming languages (notably C++) permit a single function name
|
|
to be defined several times, for application in different contexts.
|
|
This is called <STRONG>overloading</STRONG>. When a function name is overloaded,
|
|
<SAMP>`break <VAR>function</VAR>'</SAMP> is not enough to tell GDB where you want
|
|
a breakpoint. If you realize this is a problem, you can use
|
|
something like <SAMP>`break <VAR>function</VAR>(<VAR>types</VAR>)'</SAMP> to specify which
|
|
particular version of the function you want. Otherwise, GDB offers
|
|
you a menu of numbered choices for different possible breakpoints, and
|
|
waits for your selection with the prompt <SAMP>`>'</SAMP>. The first two
|
|
options are always <SAMP>`[0] cancel'</SAMP> and <SAMP>`[1] all'</SAMP>. Typing <KBD>1</KBD>
|
|
sets a breakpoint at each definition of <VAR>function</VAR>, and typing
|
|
<KBD>0</KBD> aborts the <CODE>break</CODE> command without setting any new
|
|
breakpoints.
|
|
|
|
</P>
|
|
<P>
|
|
For example, the following session excerpt shows an attempt to set a
|
|
breakpoint at the overloaded symbol <CODE>String::after</CODE>.
|
|
We choose three particular definitions of that function name:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) b String::after
|
|
[0] cancel
|
|
[1] all
|
|
[2] file:String.cc; line number:867
|
|
[3] file:String.cc; line number:860
|
|
[4] file:String.cc; line number:875
|
|
[5] file:String.cc; line number:853
|
|
[6] file:String.cc; line number:846
|
|
[7] file:String.cc; line number:735
|
|
> 2 4 6
|
|
Breakpoint 1 at 0xb26c: file String.cc, line 867.
|
|
Breakpoint 2 at 0xb344: file String.cc, line 875.
|
|
Breakpoint 3 at 0xafcc: file String.cc, line 846.
|
|
Multiple breakpoints were set.
|
|
Use the "delete" command to delete unwanted
|
|
breakpoints.
|
|
(gdb)
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC37" HREF="gdb_toc.html#TOC37">Continuing and stepping</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX142"></A>
|
|
<A NAME="IDX143"></A>
|
|
<A NAME="IDX144"></A>
|
|
<STRONG>Continuing</STRONG> means resuming program execution until your program
|
|
completes normally. In contrast, <STRONG>stepping</STRONG> means executing just
|
|
one more "step" of your program, where "step" may mean either one
|
|
line of source code, or one machine instruction (depending on what
|
|
particular command you use). Either when continuing
|
|
or when stepping, your program may stop even sooner, due to
|
|
a breakpoint or a signal. (If due to a signal, you may want to use
|
|
<CODE>handle</CODE>, or use <SAMP>`signal 0'</SAMP> to resume execution.
|
|
See section <A HREF="gdb.html#SEC38">Signals</A>.)
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>continue [<VAR>ignore-count</VAR>]</CODE>
|
|
<DD>
|
|
<A NAME="IDX145"></A>
|
|
<A NAME="IDX146"></A>
|
|
<A NAME="IDX147"></A>
|
|
|
|
<DT><CODE>c [<VAR>ignore-count</VAR>]</CODE>
|
|
<DD>
|
|
<DT><CODE>fg [<VAR>ignore-count</VAR>]</CODE>
|
|
<DD>
|
|
Resume program execution, at the address where your program last stopped;
|
|
any breakpoints set at that address are bypassed. The optional argument
|
|
<VAR>ignore-count</VAR> allows you to specify a further number of times to
|
|
ignore a breakpoint at this location; its effect is like that of
|
|
<CODE>ignore</CODE> (see section <A HREF="gdb.html#SEC34">Break conditions</A>).
|
|
|
|
The argument <VAR>ignore-count</VAR> is meaningful only when your program
|
|
stopped due to a breakpoint. At other times, the argument to
|
|
<CODE>continue</CODE> is ignored.
|
|
|
|
The synonyms <CODE>c</CODE> and <CODE>fg</CODE> are provided purely for convenience,
|
|
and have exactly the same behavior as <CODE>continue</CODE>.
|
|
</DL>
|
|
|
|
<P>
|
|
To resume execution at a different place, you can use <CODE>return</CODE>
|
|
(see section <A HREF="gdb.html#SEC95">Returning from a function</A>) to go back to the
|
|
calling function; or <CODE>jump</CODE> (see section <A HREF="gdb.html#SEC93">Continuing at a different address</A>) to go to an arbitrary location in your program.
|
|
|
|
</P>
|
|
<P>
|
|
A typical technique for using stepping is to set a breakpoint
|
|
(see section <A HREF="gdb.html#SEC28">Breakpoints, watchpoints, and exceptions</A>)
|
|
at the
|
|
beginning of the function or the section of your program where a
|
|
problem is believed to lie, run your program until it stops at that
|
|
breakpoint, and then step through the suspect area, examining the
|
|
variables that are interesting, until you see the problem happen.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>step</CODE>
|
|
<DD>
|
|
<A NAME="IDX148"></A>
|
|
<A NAME="IDX149"></A>
|
|
|
|
Continue running your program until control reaches a different source
|
|
line, then stop it and return control to GDB. This command is
|
|
abbreviated <CODE>s</CODE>.
|
|
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> If you use the <CODE>step</CODE> command while control is
|
|
within a function that was compiled without debugging information,
|
|
execution proceeds until control reaches a function that does have
|
|
debugging information. Likewise, it will not step into a function which
|
|
is compiled without debugging information. To step through functions
|
|
without debugging information, use the <CODE>stepi</CODE> command, described
|
|
below.
|
|
</BLOCKQUOTE>
|
|
|
|
The <CODE>step</CODE> command now only stops at the first instruction of a
|
|
source line. This prevents the multiple stops that used to occur in
|
|
switch statements, for loops, etc. <CODE>step</CODE> continues to stop if a
|
|
function that has debugging information is called within the line.
|
|
|
|
Also, the <CODE>step</CODE> command now only enters a subroutine if there is line
|
|
number information for the subroutine. Otherwise it acts like the
|
|
<CODE>next</CODE> command. This avoids problems when using <CODE>cc -gl</CODE>
|
|
on MIPS machines. Previously, <CODE>step</CODE> entered subroutines if there
|
|
was any debugging information about the routine.
|
|
|
|
<DT><CODE>step <VAR>count</VAR></CODE>
|
|
<DD>
|
|
Continue running as in <CODE>step</CODE>, but do so <VAR>count</VAR> times. If a
|
|
breakpoint is reached,
|
|
or a signal not related to stepping occurs before <VAR>count</VAR> steps,
|
|
stepping stops right away.
|
|
|
|
<A NAME="IDX150"></A>
|
|
<A NAME="IDX151"></A>
|
|
<DT><CODE>next [<VAR>count</VAR>]</CODE>
|
|
<DD>
|
|
Continue to the next source line in the current (innermost) stack frame.
|
|
This is similar to <CODE>step</CODE>, but function calls that appear within the line
|
|
of code are executed without stopping. Execution stops when control
|
|
reaches a different line of code at the original stack level that was
|
|
executing when you gave the <CODE>next</CODE> command. This command is abbreviated
|
|
<CODE>n</CODE>.
|
|
|
|
An argument <VAR>count</VAR> is a repeat count, as for <CODE>step</CODE>.
|
|
|
|
The <CODE>next</CODE> command now only stops at the first instruction of a
|
|
source line. This prevents the multiple stops that used to occur in
|
|
swtch statements, for loops, etc.
|
|
|
|
<A NAME="IDX152"></A>
|
|
<DT><CODE>finish</CODE>
|
|
<DD>
|
|
Continue running until just after function in the selected stack frame
|
|
returns. Print the returned value (if any).
|
|
|
|
Contrast this with the <CODE>return</CODE> command (see section <A HREF="gdb.html#SEC95">Returning from a function</A>).
|
|
|
|
<A NAME="IDX153"></A>
|
|
<DT><CODE>u</CODE>
|
|
<DD>
|
|
<A NAME="IDX154"></A>
|
|
<DT><CODE>until</CODE>
|
|
<DD>
|
|
Continue running until a source line past the current line, in the
|
|
current stack frame, is reached. This command is used to avoid single
|
|
stepping through a loop more than once. It is like the <CODE>next</CODE>
|
|
command, except that when <CODE>until</CODE> encounters a jump, it
|
|
automatically continues execution until the program counter is greater
|
|
than the address of the jump.
|
|
|
|
This means that when you reach the end of a loop after single stepping
|
|
though it, <CODE>until</CODE> makes your program continue execution until it
|
|
exits the loop. In contrast, a <CODE>next</CODE> command at the end of a loop
|
|
simply steps back to the beginning of the loop, which forces you to step
|
|
through the next iteration.
|
|
|
|
<CODE>until</CODE> always stops your program if it attempts to exit the current
|
|
stack frame.
|
|
|
|
<CODE>until</CODE> may produce somewhat counterintuitive results if the order
|
|
of machine code does not match the order of the source lines. For
|
|
example, in the following excerpt from a debugging session, the <CODE>f</CODE>
|
|
(<CODE>frame</CODE>) command shows that execution is stopped at line
|
|
<CODE>206</CODE>; yet when we use <CODE>until</CODE>, we get to line <CODE>195</CODE>:
|
|
|
|
|
|
<PRE>
|
|
(gdb) f
|
|
#0 main (argc=4, argv=0xf7fffae8) at m4.c:206
|
|
206 expand_input();
|
|
(gdb) until
|
|
195 for ( ; argc > 0; NEXTARG) {
|
|
</PRE>
|
|
|
|
This happened because, for execution efficiency, the compiler had
|
|
generated code for the loop closure test at the end, rather than the
|
|
start, of the loop--even though the test in a C <CODE>for</CODE>-loop is
|
|
written before the body of the loop. The <CODE>until</CODE> command appeared
|
|
to step back to the beginning of the loop when it advanced to this
|
|
expression; however, it has not really gone to an earlier
|
|
statement--not in terms of the actual machine code.
|
|
|
|
<CODE>until</CODE> with no argument works by means of single
|
|
instruction stepping, and hence is slower than <CODE>until</CODE> with an
|
|
argument.
|
|
|
|
<DT><CODE>until <VAR>location</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>u <VAR>location</VAR></CODE>
|
|
<DD>
|
|
Continue running your program until either the specified location is
|
|
reached, or the current stack frame returns. <VAR>location</VAR> is any of
|
|
the forms of argument acceptable to <CODE>break</CODE> (see section <A HREF="gdb.html#SEC29">Setting breakpoints</A>). This form of the command uses breakpoints,
|
|
and hence is quicker than <CODE>until</CODE> without an argument.
|
|
|
|
<A NAME="IDX155"></A>
|
|
<A NAME="IDX156"></A>
|
|
<DT><CODE>stepi</CODE>
|
|
<DD>
|
|
<DT><CODE>si</CODE>
|
|
<DD>
|
|
Execute one machine instruction, then stop and return to the debugger.
|
|
|
|
It is often useful to do <SAMP>`display/i $pc'</SAMP> when stepping by machine
|
|
instructions. This makes GDB automatically display the next
|
|
instruction to be executed, each time your program stops. See section <A HREF="gdb.html#SEC57">Automatic display</A>.
|
|
|
|
An argument is a repeat count, as in <CODE>step</CODE>.
|
|
|
|
<A NAME="IDX157"></A>
|
|
<A NAME="IDX158"></A>
|
|
<DT><CODE>nexti</CODE>
|
|
<DD>
|
|
<DT><CODE>ni</CODE>
|
|
<DD>
|
|
Execute one machine instruction, but if it is a function call,
|
|
proceed until the function returns.
|
|
|
|
An argument is a repeat count, as in <CODE>next</CODE>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC38" HREF="gdb_toc.html#TOC38">Signals</A></H2>
|
|
<P>
|
|
<A NAME="IDX159"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A signal is an asynchronous event that can happen in a program. The
|
|
operating system defines the possible kinds of signals, and gives each
|
|
kind a name and a number. For example, in Unix <CODE>SIGINT</CODE> is the
|
|
signal a program gets when you type an interrupt (often <KBD>C-c</KBD>);
|
|
<CODE>SIGSEGV</CODE> is the signal a program gets from referencing a place in
|
|
memory far away from all the areas in use; <CODE>SIGALRM</CODE> occurs when
|
|
the alarm clock timer goes off (which happens only if your program has
|
|
requested an alarm).
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX160"></A>
|
|
Some signals, including <CODE>SIGALRM</CODE>, are a normal part of the
|
|
functioning of your program. Others, such as <CODE>SIGSEGV</CODE>, indicate
|
|
errors; these signals are <STRONG>fatal</STRONG> (kill your program immediately) if the
|
|
program has not specified in advance some other way to handle the signal.
|
|
<CODE>SIGINT</CODE> does not indicate an error in your program, but it is normally
|
|
fatal so it can carry out the purpose of the interrupt: to kill the program.
|
|
|
|
</P>
|
|
<P>
|
|
GDB has the ability to detect any occurrence of a signal in your
|
|
program. You can tell GDB in advance what to do for each kind of
|
|
signal.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX161"></A>
|
|
Normally, GDB is set up to ignore non-erroneous signals like <CODE>SIGALRM</CODE>
|
|
(so as not to interfere with their role in the functioning of your program)
|
|
but to stop your program immediately whenever an error signal happens.
|
|
You can change these settings with the <CODE>handle</CODE> command.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info signals</CODE>
|
|
<DD>
|
|
<A NAME="IDX162"></A>
|
|
|
|
Print a table of all the kinds of signals and how GDB has been told to
|
|
handle each one. You can use this to see the signal numbers of all
|
|
the defined types of signals.
|
|
|
|
<CODE>info handle</CODE> is the new alias for <CODE>info signals</CODE>.
|
|
|
|
<A NAME="IDX163"></A>
|
|
<DT><CODE>handle <VAR>signal</VAR> <VAR>keywords</VAR>...</CODE>
|
|
<DD>
|
|
Change the way GDB handles signal <VAR>signal</VAR>. <VAR>signal</VAR> can
|
|
be the number of a signal or its name (with or without the <SAMP>`SIG'</SAMP> at the
|
|
beginning). The <VAR>keywords</VAR> say what change to make.
|
|
</DL>
|
|
|
|
<P>
|
|
The keywords allowed by the <CODE>handle</CODE> command can be abbreviated.
|
|
Their full names are:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>nostop</CODE>
|
|
<DD>
|
|
GDB should not stop your program when this signal happens. It may
|
|
still print a message telling you that the signal has come in.
|
|
|
|
<DT><CODE>stop</CODE>
|
|
<DD>
|
|
GDB should stop your program when this signal happens. This implies
|
|
the <CODE>print</CODE> keyword as well.
|
|
|
|
<DT><CODE>print</CODE>
|
|
<DD>
|
|
GDB should print a message when this signal happens.
|
|
|
|
<DT><CODE>noprint</CODE>
|
|
<DD>
|
|
GDB should not mention the occurrence of the signal at all. This
|
|
implies the <CODE>nostop</CODE> keyword as well.
|
|
|
|
<DT><CODE>pass</CODE>
|
|
<DD>
|
|
GDB should allow your program to see this signal; your program
|
|
can handle the signal, or else it may terminate if the signal is fatal
|
|
and not handled.
|
|
|
|
<DT><CODE>nopass</CODE>
|
|
<DD>
|
|
GDB should not allow your program to see this signal.
|
|
</DL>
|
|
|
|
<P>
|
|
When a signal stops your program, the signal is not visible until you
|
|
continue. Your program sees the signal then, if <CODE>pass</CODE> is in
|
|
effect for the signal in question <EM>at that time</EM>. In other words,
|
|
after GDB reports a signal, you can use the <CODE>handle</CODE>
|
|
command with <CODE>pass</CODE> or <CODE>nopass</CODE> to control whether your
|
|
program sees that signal when you continue.
|
|
|
|
</P>
|
|
<P>
|
|
You can also use the <CODE>signal</CODE> command to prevent your program from
|
|
seeing a signal, or cause it to see a signal it normally would not see,
|
|
or to give it any signal at any time. For example, if your program stopped
|
|
due to some sort of memory reference error, you might store correct
|
|
values into the erroneous variables and continue, hoping to see more
|
|
execution; but your program would probably terminate immediately as
|
|
a result of the fatal signal once it saw the signal. To prevent this,
|
|
you can continue with <SAMP>`signal 0'</SAMP>. See section <A HREF="gdb.html#SEC94">Giving your program a signal</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC39" HREF="gdb_toc.html#TOC39">Stopping and starting multi-thread programs</A></H2>
|
|
|
|
<P>
|
|
When your program has multiple threads (see section <A HREF="gdb.html#SEC25">Debugging programs with multiple threads</A>), you can choose whether to set
|
|
breakpoints on all threads, or on a particular thread.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>break <VAR>linespec</VAR> thread <VAR>threadno</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX164"></A>
|
|
<A NAME="IDX165"></A>
|
|
<A NAME="IDX166"></A>
|
|
|
|
<DT><CODE>break <VAR>linespec</VAR> thread <VAR>threadno</VAR> if ...</CODE>
|
|
<DD>
|
|
<VAR>linespec</VAR> specifies source lines; there are several ways of
|
|
writing them, but the effect is always to specify some source line.
|
|
|
|
Use the qualifier <SAMP>`thread <VAR>threadno</VAR>'</SAMP> with a breakpoint command
|
|
to specify that you only want GDB to stop the program when a
|
|
particular thread reaches this breakpoint. <VAR>threadno</VAR> is one of the
|
|
numeric thread identifiers assigned by GDB, shown in the first
|
|
column of the <SAMP>`info threads'</SAMP> display.
|
|
|
|
If you do not specify <SAMP>`thread <VAR>threadno</VAR>'</SAMP> when you set a
|
|
breakpoint, the breakpoint applies to <EM>all</EM> threads of your
|
|
program.
|
|
|
|
You can use the <CODE>thread</CODE> qualifier on conditional breakpoints as
|
|
well; in this case, place <SAMP>`thread <VAR>threadno</VAR>'</SAMP> before the
|
|
breakpoint condition, like this:
|
|
|
|
|
|
<PRE>
|
|
(gdb) break frik.c:13 thread 28 if bartab > lim
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX167"></A>
|
|
<A NAME="IDX168"></A>
|
|
Whenever your program stops under GDB for any reason,
|
|
<EM>all</EM> threads of execution stop, not just the current thread. This
|
|
allows you to examine the overall state of the program, including
|
|
switching between threads, without worrying that things may change
|
|
underfoot.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX169"></A>
|
|
<A NAME="IDX170"></A>
|
|
Conversely, whenever you restart the program, <EM>all</EM> threads start
|
|
executing. <EM>This is true even when single-stepping</EM> with commands
|
|
like <CODE>step</CODE> or <CODE>next</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
In particular, GDB cannot single-step all threads in lockstep.
|
|
Since thread scheduling is up to your debugging target's operating
|
|
system (not controlled by GDB), other threads may
|
|
execute more than one statement while the current thread completes a
|
|
single step. Moreover, in general other threads stop in the middle of a
|
|
statement, rather than at a clean statement boundary, when the program
|
|
stops.
|
|
|
|
</P>
|
|
<P>
|
|
You might even find your program stopped in another thread after
|
|
continuing or even single-stepping. This happens whenever some other
|
|
thread runs into a breakpoint, a signal, or an exception before the
|
|
first thread completes whatever you requested.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC40" HREF="gdb_toc.html#TOC40">Examining the Stack</A></H1>
|
|
|
|
<P>
|
|
When your program has stopped, the first thing you need to know is where it
|
|
stopped and how it got there.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX171"></A>
|
|
Each time your program performs a function call, information about the call
|
|
is generated.
|
|
That information includes the location of the call in your program,
|
|
the arguments of the call,
|
|
and the local variables of the function being called.
|
|
The information is saved in a block of data called a <STRONG>stack frame</STRONG>.
|
|
The stack frames are allocated in a region of memory called the <STRONG>call
|
|
stack</STRONG>.
|
|
|
|
</P>
|
|
<P>
|
|
When your program stops, the GDB commands for examining the
|
|
stack allow you to see all of this information.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX172"></A>
|
|
One of the stack frames is <STRONG>selected</STRONG> by GDB and many
|
|
GDB commands refer implicitly to the selected frame. In
|
|
particular, whenever you ask GDB for the value of a variable in
|
|
your program, the value is found in the selected frame. There are
|
|
special GDB commands to select whichever frame you are
|
|
interested in. See section <A HREF="gdb.html#SEC43">Selecting a frame</A>.
|
|
|
|
</P>
|
|
<P>
|
|
When your program stops, GDB automatically selects the
|
|
currently executing frame and describes it briefly, similar to the
|
|
<CODE>frame</CODE> command (see section <A HREF="gdb.html#SEC44">Information about a frame</A>).
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC41" HREF="gdb_toc.html#TOC41">Stack frames</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX173"></A>
|
|
<A NAME="IDX174"></A>
|
|
The call stack is divided up into contiguous pieces called <STRONG>stack
|
|
frames</STRONG>, or <STRONG>frames</STRONG> for short; each frame is the data associated
|
|
with one call to one function. The frame contains the arguments given
|
|
to the function, the function's local variables, and the address at
|
|
which the function is executing.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX175"></A>
|
|
<A NAME="IDX176"></A>
|
|
<A NAME="IDX177"></A>
|
|
When your program is started, the stack has only one frame, that of the
|
|
function <CODE>main</CODE>. This is called the <STRONG>initial</STRONG> frame or the
|
|
<STRONG>outermost</STRONG> frame. Each time a function is called, a new frame is
|
|
made. Each time a function returns, the frame for that function invocation
|
|
is eliminated. If a function is recursive, there can be many frames for
|
|
the same function. The frame for the function in which execution is
|
|
actually occurring is called the <STRONG>innermost</STRONG> frame. This is the most
|
|
recently created of all the stack frames that still exist.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX178"></A>
|
|
Inside your program, stack frames are identified by their addresses. A
|
|
stack frame consists of many bytes, each of which has its own address; each
|
|
kind of computer has a convention for choosing one byte whose
|
|
address serves as the address of the frame. Usually this address is kept
|
|
in a register called the <STRONG>frame pointer register</STRONG> while execution is
|
|
going on in that frame.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX179"></A>
|
|
GDB assigns numbers to all existing stack frames, starting with
|
|
zero for the innermost frame, one for the frame that called it,
|
|
and so on upward. These numbers do not really exist in your program;
|
|
they are assigned by GDB to give you a way of designating stack
|
|
frames in GDB commands.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX180"></A>
|
|
Some compilers provide a way to compile functions so that they operate
|
|
without stack frames. (For example, the <CODE>gcc</CODE> option
|
|
<SAMP>`-fomit-frame-pointer'</SAMP> generates functions without a frame.)
|
|
This is occasionally done with heavily used library functions to save
|
|
the frame setup time. GDB has limited facilities for dealing
|
|
with these function invocations. If the innermost function invocation
|
|
has no stack frame, GDB nevertheless regards it as though
|
|
it had a separate frame, which is numbered zero as usual, allowing
|
|
correct tracing of the function call chain. However, GDB has
|
|
no provision for frameless functions elsewhere in the stack.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>frame <VAR>args</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX181"></A>
|
|
|
|
The <CODE>frame</CODE> command allows you to move from one stack frame to another,
|
|
and to print the stack frame you select. <VAR>args</VAR> may be either the
|
|
address of the frame or the stack frame number. Without an argument,
|
|
<CODE>frame</CODE> prints the current stack frame.
|
|
|
|
<A NAME="IDX182"></A>
|
|
<DT><CODE>select-frame</CODE>
|
|
<DD>
|
|
The <CODE>select-frame</CODE> command allows you to move from one stack frame
|
|
to another without printing the frame. This is the silent version of
|
|
<CODE>frame</CODE>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC42" HREF="gdb_toc.html#TOC42">Backtraces</A></H2>
|
|
|
|
<P>
|
|
A backtrace is a summary of how your program got where it is. It shows one
|
|
line per frame, for many frames, starting with the currently executing
|
|
frame (frame zero), followed by its caller (frame one), and on up the
|
|
stack.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>backtrace</CODE>
|
|
<DD>
|
|
<A NAME="IDX183"></A>
|
|
<A NAME="IDX184"></A>
|
|
|
|
<DT><CODE>bt</CODE>
|
|
<DD>
|
|
Print a backtrace of the entire stack: one line per frame for all
|
|
frames in the stack.
|
|
|
|
You can stop the backtrace at any time by typing the system interrupt
|
|
character, normally <KBD>C-c</KBD>.
|
|
|
|
<DT><CODE>backtrace <VAR>n</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>bt <VAR>n</VAR></CODE>
|
|
<DD>
|
|
Similar, but print only the innermost <VAR>n</VAR> frames.
|
|
|
|
<DT><CODE>backtrace -<VAR>n</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>bt -<VAR>n</VAR></CODE>
|
|
<DD>
|
|
Similar, but print only the outermost <VAR>n</VAR> frames.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX185"></A>
|
|
<A NAME="IDX186"></A>
|
|
<A NAME="IDX187"></A>
|
|
The names <CODE>where</CODE> and <CODE>info stack</CODE> (abbreviated <CODE>info s</CODE>)
|
|
are additional aliases for <CODE>backtrace</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
Each line in the backtrace shows the frame number and the function name.
|
|
The program counter value is also shown--unless you use <CODE>set
|
|
print address off</CODE>. The backtrace also shows the source file name and
|
|
line number, as well as the arguments to the function. The program
|
|
counter value is omitted if it is at the beginning of the code for that
|
|
line number.
|
|
|
|
</P>
|
|
<P>
|
|
Here is an example of a backtrace. It was made with the command
|
|
<SAMP>`bt 3'</SAMP>, so it shows the innermost three frames.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
#0 m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8)
|
|
at builtin.c:993
|
|
#1 0x6e38 in expand_macro (sym=0x2b600) at macro.c:242
|
|
#2 0x6840 in expand_token (obs=0x0, t=177664, td=0xf7fffb08)
|
|
at macro.c:71
|
|
(More stack frames follow...)
|
|
</PRE>
|
|
|
|
<P>
|
|
The display for frame zero does not begin with a program counter
|
|
value, indicating that your program has stopped at the beginning of the
|
|
code for line <CODE>993</CODE> of <CODE>builtin.c</CODE>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC43" HREF="gdb_toc.html#TOC43">Selecting a frame</A></H2>
|
|
|
|
<P>
|
|
Most commands for examining the stack and other data in your program work on
|
|
whichever stack frame is selected at the moment. Here are the commands for
|
|
selecting a stack frame; all of them finish by printing a brief description
|
|
of the stack frame just selected.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>frame <VAR>n</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX188"></A>
|
|
<A NAME="IDX189"></A>
|
|
|
|
<DT><CODE>f <VAR>n</VAR></CODE>
|
|
<DD>
|
|
Select frame number <VAR>n</VAR>. Recall that frame zero is the innermost
|
|
(currently executing) frame, frame one is the frame that called the
|
|
innermost one, and so on. The highest-numbered frame is the one for
|
|
<CODE>main</CODE>.
|
|
|
|
<DT><CODE>frame <VAR>addr</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>f <VAR>addr</VAR></CODE>
|
|
<DD>
|
|
Select the frame at address <VAR>addr</VAR>. This is useful mainly if the
|
|
chaining of stack frames has been damaged by a bug, making it
|
|
impossible for GDB to assign numbers properly to all frames. In
|
|
addition, this can be useful when your program has multiple stacks and
|
|
switches between them.
|
|
|
|
On the SPARC architecture, <CODE>frame</CODE> needs two addresses to
|
|
select an arbitrary frame: a frame pointer and a stack pointer.
|
|
|
|
On the MIPS and Alpha architecture, it needs two addresses: a stack
|
|
pointer and a program counter.
|
|
|
|
On the 29k architecture, it needs three addresses: a register stack
|
|
pointer, a program counter, and a memory stack pointer.
|
|
|
|
<A NAME="IDX190"></A>
|
|
<DT><CODE>up <VAR>n</VAR></CODE>
|
|
<DD>
|
|
Move <VAR>n</VAR> frames up the stack. For positive numbers <VAR>n</VAR>, this
|
|
advances toward the outermost frame, to higher frame numbers, to frames
|
|
that have existed longer. <VAR>n</VAR> defaults to one.
|
|
|
|
<A NAME="IDX191"></A>
|
|
<A NAME="IDX192"></A>
|
|
<DT><CODE>down <VAR>n</VAR></CODE>
|
|
<DD>
|
|
Move <VAR>n</VAR> frames down the stack. For positive numbers <VAR>n</VAR>, this
|
|
advances toward the innermost frame, to lower frame numbers, to frames
|
|
that were created more recently. <VAR>n</VAR> defaults to one. You may
|
|
abbreviate <CODE>down</CODE> as <CODE>do</CODE>.
|
|
</DL>
|
|
|
|
<P>
|
|
All of these commands end by printing two lines of output describing the
|
|
frame. The first line shows the frame number, the function name, the
|
|
arguments, and the source file and line number of execution in that
|
|
frame. The second line shows the text of that source line.
|
|
|
|
</P>
|
|
<P>
|
|
For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) up
|
|
#1 0x22f0 in main (argc=1, argv=0xf7fffbf4, env=0xf7fffbfc)
|
|
at env.c:10
|
|
10 read_input_file (argv[i]);
|
|
</PRE>
|
|
|
|
<P>
|
|
After such a printout, the <CODE>list</CODE> command with no arguments
|
|
prints ten lines centered on the point of execution in the frame.
|
|
See section <A HREF="gdb.html#SEC47">Printing source lines</A>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>up-silently <VAR>n</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX193"></A>
|
|
<A NAME="IDX194"></A>
|
|
|
|
<DT><CODE>down-silently <VAR>n</VAR></CODE>
|
|
<DD>
|
|
These two commands are variants of <CODE>up</CODE> and <CODE>down</CODE>,
|
|
respectively; they differ in that they do their work silently, without
|
|
causing display of the new frame. They are intended primarily for use
|
|
in GDB command scripts, where the output might be unnecessary and
|
|
distracting.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC44" HREF="gdb_toc.html#TOC44">Information about a frame</A></H2>
|
|
|
|
<P>
|
|
There are several other commands to print information about the selected
|
|
stack frame.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>frame</CODE>
|
|
<DD>
|
|
<DT><CODE>f</CODE>
|
|
<DD>
|
|
When used without any argument, this command does not change which
|
|
frame is selected, but prints a brief description of the currently
|
|
selected stack frame. It can be abbreviated <CODE>f</CODE>. With an
|
|
argument, this command is used to select a stack frame.
|
|
See section <A HREF="gdb.html#SEC43">Selecting a frame</A>.
|
|
|
|
<A NAME="IDX195"></A>
|
|
<A NAME="IDX196"></A>
|
|
<DT><CODE>info frame</CODE>
|
|
<DD>
|
|
<DT><CODE>info f</CODE>
|
|
<DD>
|
|
This command prints a verbose description of the selected stack frame,
|
|
including:
|
|
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
the address of the frame
|
|
<LI>
|
|
|
|
the address of the next frame down (called by this frame)
|
|
<LI>
|
|
|
|
the address of the next frame up (caller of this frame)
|
|
<LI>
|
|
|
|
the language in which the source code corresponding to this frame is written
|
|
<LI>
|
|
|
|
the address of the frame's arguments
|
|
<LI>
|
|
|
|
the program counter saved in it (the address of execution in the caller frame)
|
|
<LI>
|
|
|
|
which registers were saved in the frame
|
|
</UL>
|
|
|
|
The verbose description is useful when
|
|
something has gone wrong that has made the stack format fail to fit
|
|
the usual conventions.
|
|
|
|
<DT><CODE>info frame <VAR>addr</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>info f <VAR>addr</VAR></CODE>
|
|
<DD>
|
|
Print a verbose description of the frame at address <VAR>addr</VAR>, without
|
|
selecting that frame. The selected frame remains unchanged by this
|
|
command. This requires the same kind of address (more than one for some
|
|
architectures) that you specify in the <CODE>frame</CODE> command.
|
|
See section <A HREF="gdb.html#SEC43">Selecting a frame</A>.
|
|
|
|
<A NAME="IDX197"></A>
|
|
<DT><CODE>info args</CODE>
|
|
<DD>
|
|
Print the arguments of the selected frame, each on a separate line.
|
|
|
|
<DT><CODE>info locals</CODE>
|
|
<DD>
|
|
<A NAME="IDX198"></A>
|
|
Print the local variables of the selected frame, each on a separate
|
|
line. These are all variables (declared either static or automatic)
|
|
accessible at the point of execution of the selected frame.
|
|
|
|
<A NAME="IDX199"></A>
|
|
<A NAME="IDX200"></A>
|
|
<A NAME="IDX201"></A>
|
|
<DT><CODE>info catch</CODE>
|
|
<DD>
|
|
Print a list of all the exception handlers that are active in the
|
|
current stack frame at the current point of execution. To see other
|
|
exception handlers, visit the associated frame (using the <CODE>up</CODE>,
|
|
<CODE>down</CODE>, or <CODE>frame</CODE> commands); then type <CODE>info catch</CODE>.
|
|
See section <A HREF="gdb.html#SEC31">Breakpoints and exceptions</A>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC45" HREF="gdb_toc.html#TOC45">MIPS machines and the function stack</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX202"></A>
|
|
<A NAME="IDX203"></A>
|
|
MIPS based computers use an unusual stack frame, which sometimes
|
|
requires GDB to search backward in the object code to find the
|
|
beginning of a function.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX204"></A>
|
|
To improve response time (especially for embedded applications, where
|
|
GDB may be restricted to a slow serial line for this search)
|
|
you may want to limit the size of this search, using one of these
|
|
commands:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set heuristic-fence-post <VAR>limit</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX205"></A>
|
|
|
|
Restrict GDB to examining at most <VAR>limit</VAR> bytes in its search
|
|
for the beginning of a function. A value of <VAR>0</VAR> (the default)
|
|
means there is no limit. However, except for <VAR>0</VAR>, the larger the
|
|
limit the more bytes <CODE>heuristic-fence-post</CODE> must search and
|
|
therefore the longer it takes to run.
|
|
|
|
<DT><CODE>show heuristic-fence-post</CODE>
|
|
<DD>
|
|
Display the current limit.
|
|
</DL>
|
|
|
|
<P>
|
|
These commands are available <EM>only</EM> when GDB is configured
|
|
for debugging programs on MIPS processors.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC46" HREF="gdb_toc.html#TOC46">Examining Source Files</A></H1>
|
|
|
|
<P>
|
|
GDB can print parts of your program's source, since the debugging
|
|
information recorded in the program tells GDB what source files were
|
|
used to build it. When your program stops, GDB spontaneously prints
|
|
the line where it stopped. Likewise, when you select a stack frame
|
|
(see section <A HREF="gdb.html#SEC43">Selecting a frame</A>), GDB prints the line where
|
|
execution in that frame has stopped. You can print other portions of
|
|
source files by explicit command.
|
|
|
|
</P>
|
|
<P>
|
|
If you use GDB through its GNU Emacs interface, you may prefer
|
|
to use
|
|
Emacs facilities to view source; see section <A HREF="gdb.html#SEC150">Using GDB under GNU Emacs</A>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC47" HREF="gdb_toc.html#TOC47">Printing source lines</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX206"></A>
|
|
<A NAME="IDX207"></A>
|
|
To print lines from a source file, use the <CODE>list</CODE> command
|
|
(abbreviated <CODE>l</CODE>). By default, ten lines are printed.
|
|
There are several ways to specify what part of the file you want to print.
|
|
|
|
</P>
|
|
<P>
|
|
Here are the forms of the <CODE>list</CODE> command most commonly used:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>list <VAR>linenum</VAR></CODE>
|
|
<DD>
|
|
Print lines centered around line number <VAR>linenum</VAR> in the
|
|
current source file.
|
|
|
|
<DT><CODE>list <VAR>function</VAR></CODE>
|
|
<DD>
|
|
Print lines centered around the beginning of function
|
|
<VAR>function</VAR>.
|
|
|
|
<DT><CODE>list</CODE>
|
|
<DD>
|
|
Print more lines. If the last lines printed were printed with a
|
|
<CODE>list</CODE> command, this prints lines following the last lines
|
|
printed; however, if the last line printed was a solitary line printed
|
|
as part of displaying a stack frame (see section <A HREF="gdb.html#SEC40">Examining the Stack</A>), this prints lines centered around that line.
|
|
|
|
<DT><CODE>list -</CODE>
|
|
<DD>
|
|
Print lines just before the lines last printed.
|
|
</DL>
|
|
|
|
<P>
|
|
By default, GDB prints ten source lines with any of these forms of
|
|
the <CODE>list</CODE> command. You can change this using <CODE>set listsize</CODE>:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set listsize <VAR>count</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX208"></A>
|
|
|
|
Make the <CODE>list</CODE> command display <VAR>count</VAR> source lines (unless
|
|
the <CODE>list</CODE> argument explicitly specifies some other number).
|
|
|
|
<A NAME="IDX209"></A>
|
|
<DT><CODE>show listsize</CODE>
|
|
<DD>
|
|
Display the number of lines that <CODE>list</CODE> prints.
|
|
</DL>
|
|
|
|
<P>
|
|
Repeating a <CODE>list</CODE> command with <KBD>RET</KBD> discards the argument,
|
|
so it is equivalent to typing just <CODE>list</CODE>. This is more useful
|
|
than listing the same lines again. An exception is made for an
|
|
argument of <SAMP>`-'</SAMP>; that argument is preserved in repetition so that
|
|
each repetition moves up in the source file.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX210"></A>
|
|
In general, the <CODE>list</CODE> command expects you to supply zero, one or two
|
|
<STRONG>linespecs</STRONG>. Linespecs specify source lines; there are several ways
|
|
of writing them but the effect is always to specify some source line.
|
|
Here is a complete description of the possible arguments for <CODE>list</CODE>:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>list <VAR>linespec</VAR></CODE>
|
|
<DD>
|
|
Print lines centered around the line specified by <VAR>linespec</VAR>.
|
|
|
|
<DT><CODE>list <VAR>first</VAR>,<VAR>last</VAR></CODE>
|
|
<DD>
|
|
Print lines from <VAR>first</VAR> to <VAR>last</VAR>. Both arguments are
|
|
linespecs.
|
|
|
|
<DT><CODE>list ,<VAR>last</VAR></CODE>
|
|
<DD>
|
|
Print lines ending with <VAR>last</VAR>.
|
|
|
|
<DT><CODE>list <VAR>first</VAR>,</CODE>
|
|
<DD>
|
|
Print lines starting with <VAR>first</VAR>.
|
|
|
|
<DT><CODE>list +</CODE>
|
|
<DD>
|
|
Print lines just after the lines last printed.
|
|
|
|
<DT><CODE>list -</CODE>
|
|
<DD>
|
|
Print lines just before the lines last printed.
|
|
|
|
<DT><CODE>list</CODE>
|
|
<DD>
|
|
As described in the preceding table.
|
|
</DL>
|
|
|
|
<P>
|
|
Here are the ways of specifying a single source line--all the
|
|
kinds of linespec.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE><VAR>number</VAR></CODE>
|
|
<DD>
|
|
Specifies line <VAR>number</VAR> of the current source file.
|
|
When a <CODE>list</CODE> command has two linespecs, this refers to
|
|
the same source file as the first linespec.
|
|
|
|
<DT><CODE>+<VAR>offset</VAR></CODE>
|
|
<DD>
|
|
Specifies the line <VAR>offset</VAR> lines after the last line printed.
|
|
When used as the second linespec in a <CODE>list</CODE> command that has
|
|
two, this specifies the line <VAR>offset</VAR> lines down from the
|
|
first linespec.
|
|
|
|
<DT><CODE>-<VAR>offset</VAR></CODE>
|
|
<DD>
|
|
Specifies the line <VAR>offset</VAR> lines before the last line printed.
|
|
|
|
<DT><CODE><VAR>filename</VAR>:<VAR>number</VAR></CODE>
|
|
<DD>
|
|
Specifies line <VAR>number</VAR> in the source file <VAR>filename</VAR>.
|
|
|
|
<DT><CODE><VAR>function</VAR></CODE>
|
|
<DD>
|
|
Specifies the line that begins the body of the function <VAR>function</VAR>.
|
|
For example: in C, this is the line with the open brace.
|
|
|
|
<DT><CODE><VAR>filename</VAR>:<VAR>function</VAR></CODE>
|
|
<DD>
|
|
Specifies the line of the open-brace that begins the body of the
|
|
function <VAR>function</VAR> in the file <VAR>filename</VAR>. You only need the
|
|
file name with a function name to avoid ambiguity when there are
|
|
identically named functions in different source files.
|
|
|
|
<DT><CODE>*<VAR>address</VAR></CODE>
|
|
<DD>
|
|
Specifies the line containing the program address <VAR>address</VAR>.
|
|
<VAR>address</VAR> may be any expression.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC48" HREF="gdb_toc.html#TOC48">Searching source files</A></H2>
|
|
<P>
|
|
<A NAME="IDX211"></A>
|
|
<A NAME="IDX212"></A>
|
|
|
|
</P>
|
|
<P>
|
|
There are two commands for searching through the current source file for a
|
|
regular expression.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>forward-search <VAR>regexp</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX213"></A>
|
|
<A NAME="IDX214"></A>
|
|
|
|
<DT><CODE>search <VAR>regexp</VAR></CODE>
|
|
<DD>
|
|
The command <SAMP>`forward-search <VAR>regexp</VAR>'</SAMP> checks each line,
|
|
starting with the one following the last line listed, for a match for
|
|
<VAR>regexp</VAR>. It lists the line that is found. You can use the
|
|
synonym <SAMP>`search <VAR>regexp</VAR>'</SAMP> or abbreviate the command name as
|
|
<CODE>fo</CODE>.
|
|
|
|
<DT><CODE>reverse-search <VAR>regexp</VAR></CODE>
|
|
<DD>
|
|
The command <SAMP>`reverse-search <VAR>regexp</VAR>'</SAMP> checks each line, starting
|
|
with the one before the last line listed and going backward, for a match
|
|
for <VAR>regexp</VAR>. It lists the line that is found. You can abbreviate
|
|
this command as <CODE>rev</CODE>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC49" HREF="gdb_toc.html#TOC49">Specifying source directories</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX215"></A>
|
|
<A NAME="IDX216"></A>
|
|
Executable programs sometimes do not record the directories of the source
|
|
files from which they were compiled, just the names. Even when they do,
|
|
the directories could be moved between the compilation and your debugging
|
|
session. GDB has a list of directories to search for source files;
|
|
this is called the <STRONG>source path</STRONG>. Each time GDB wants a source file,
|
|
it tries all the directories in the list, in the order they are present
|
|
in the list, until it finds a file with the desired name. Note that
|
|
the executable search path is <EM>not</EM> used for this purpose. Neither is
|
|
the current working directory, unless it happens to be in the source
|
|
path.
|
|
|
|
</P>
|
|
<P>
|
|
If GDB cannot find a source file in the source path, and the
|
|
object program records a directory, GDB tries that directory
|
|
too. If the source path is empty, and there is no record of the
|
|
compilation directory, GDB looks in the current directory as a
|
|
last resort.
|
|
|
|
</P>
|
|
<P>
|
|
Whenever you reset or rearrange the source path, GDB clears out
|
|
any information it has cached about where source files are found and where
|
|
each line is in the file.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX217"></A>
|
|
<A NAME="IDX218"></A>
|
|
When you start GDB, its source path is empty.
|
|
To add other directories, use the <CODE>directory</CODE> command.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>directory <VAR>dirname</VAR> ...</CODE>
|
|
<DD>
|
|
<DT><CODE>dir <VAR>dirname</VAR> ...</CODE>
|
|
<DD>
|
|
Add directory <VAR>dirname</VAR> to the front of the source path. Several
|
|
directory names may be given to this command, separated by <SAMP>`:'</SAMP> or
|
|
whitespace. You may specify a directory that is already in the source
|
|
path; this moves it forward, so GDB searches it sooner.
|
|
|
|
<A NAME="IDX219"></A>
|
|
<A NAME="IDX220"></A>
|
|
<A NAME="IDX221"></A>
|
|
<A NAME="IDX222"></A>
|
|
<A NAME="IDX223"></A>
|
|
<A NAME="IDX224"></A>
|
|
<A NAME="IDX225"></A>
|
|
<A NAME="IDX226"></A>
|
|
<A NAME="IDX227"></A>
|
|
You can use the string <SAMP>`$cdir'</SAMP> to refer to the compilation
|
|
directory (if one is recorded), and <SAMP>`$cwd'</SAMP> to refer to the current
|
|
working directory. <SAMP>`$cwd'</SAMP> is not the same as <SAMP>`.'</SAMP>---the former
|
|
tracks the current working directory as it changes during your GDB
|
|
session, while the latter is immediately expanded to the current
|
|
directory at the time you add an entry to the source path.
|
|
|
|
<DT><CODE>directory</CODE>
|
|
<DD>
|
|
Reset the source path to empty again. This requires confirmation.
|
|
|
|
<DT><CODE>show directories</CODE>
|
|
<DD>
|
|
<A NAME="IDX228"></A>
|
|
Print the source path: show which directories it contains.
|
|
</DL>
|
|
|
|
<P>
|
|
If your source path is cluttered with directories that are no longer of
|
|
interest, GDB may sometimes cause confusion by finding the wrong
|
|
versions of source. You can correct the situation as follows:
|
|
|
|
</P>
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
Use <CODE>directory</CODE> with no argument to reset the source path to empty.
|
|
|
|
<LI>
|
|
|
|
Use <CODE>directory</CODE> with suitable arguments to reinstall the
|
|
directories you want in the source path. You can add all the
|
|
directories in one command.
|
|
</OL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC50" HREF="gdb_toc.html#TOC50">Source and machine code</A></H2>
|
|
|
|
<P>
|
|
You can use the command <CODE>info line</CODE> to map source lines to program
|
|
addresses (and vice versa), and the command <CODE>disassemble</CODE> to display
|
|
a range of addresses as machine instructions. When run under GNU Emacs
|
|
mode, the <CODE>info line</CODE> command now causes the arrow to point to the
|
|
line specified. Also, <CODE>info line</CODE> prints addresses in symbolic form as
|
|
well as hex.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info line <VAR>linespec</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX229"></A>
|
|
|
|
Print the starting and ending addresses of the compiled code for
|
|
source line <VAR>linespec</VAR>. You can specify source lines in any of
|
|
the ways understood by the <CODE>list</CODE> command (see section <A HREF="gdb.html#SEC47">Printing source lines</A>).
|
|
</DL>
|
|
|
|
<P>
|
|
For example, we can use <CODE>info line</CODE> to discover the location of
|
|
the object code for the first line of function
|
|
<CODE>m4_changequote</CODE>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) info line m4_changecom
|
|
Line 895 of "builtin.c" starts at pc 0x634c and ends at 0x6350.
|
|
</PRE>
|
|
|
|
<P>
|
|
We can also inquire (using <CODE>*<VAR>addr</VAR></CODE> as the form for
|
|
<VAR>linespec</VAR>) what source line covers a particular address:
|
|
|
|
<PRE>
|
|
(gdb) info line *0x63ff
|
|
Line 926 of "builtin.c" starts at pc 0x63e4 and ends at 0x6404.
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX230"></A>
|
|
After <CODE>info line</CODE>, the default address for the <CODE>x</CODE> command
|
|
is changed to the starting address of the line, so that <SAMP>`x/i'</SAMP> is
|
|
sufficient to begin examining the machine code (see section <A HREF="gdb.html#SEC56">Examining memory</A>). Also, this address is saved as the value of the
|
|
convenience variable <CODE>$_</CODE> (see section <A HREF="gdb.html#SEC60">Convenience variables</A>).
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>disassemble</CODE>
|
|
<DD>
|
|
<A NAME="IDX231"></A>
|
|
<A NAME="IDX232"></A>
|
|
<A NAME="IDX233"></A>
|
|
<A NAME="IDX234"></A>
|
|
<A NAME="IDX235"></A>
|
|
|
|
This specialized command dumps a range of memory as machine
|
|
instructions. The default memory range is the function surrounding the
|
|
program counter of the selected frame. A single argument to this
|
|
command is a program counter value; GDB dumps the function
|
|
surrounding this value. Two arguments specify a range of addresses
|
|
(first inclusive, second exclusive) to dump.
|
|
</DL>
|
|
|
|
<P>
|
|
We can use <CODE>disassemble</CODE> to inspect the object code
|
|
range shown in the last <CODE>info line</CODE> example (the example
|
|
shows SPARC machine instructions):
|
|
|
|
</P>
|
|
|
|
|
|
<PRE>
|
|
(gdb) disas 0x63e4 0x6404
|
|
Dump of assembler code from 0x63e4 to 0x6404:
|
|
0x63e4 <builtin_init+5340>: ble 0x63f8 <builtin_init+5360>
|
|
0x63e8 <builtin_init+5344>: sethi %hi(0x4c00), %o0
|
|
0x63ec <builtin_init+5348>: ld [%i1+4], %o0
|
|
0x63f0 <builtin_init+5352>: b 0x63fc <builtin_init+5364>
|
|
0x63f4 <builtin_init+5356>: ld [%o0+4], %o0
|
|
0x63f8 <builtin_init+5360>: or %o0, 0x1a4, %o0
|
|
0x63fc <builtin_init+5364>: call 0x9288 <path_search>
|
|
0x6400 <builtin_init+5368>: nop
|
|
End of assembler dump.
|
|
</PRE>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set assembly-language <VAR>instruction-set</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX236"></A>
|
|
<A NAME="IDX237"></A>
|
|
<A NAME="IDX238"></A>
|
|
<A NAME="IDX239"></A>
|
|
<A NAME="IDX240"></A>
|
|
|
|
This command selects the instruction set to use when disassembling the program via the
|
|
<CODE>disassemble</CODE> or <CODE>x/i</CODE> commands. It is useful for architectures that
|
|
have more than one native instruction set.
|
|
|
|
Currently it is only defined for the Intel x86 family. You can set <VAR>instruction-set</VAR>
|
|
to either <CODE>i386</CODE> or <CODE>i8086</CODE>. The default is <CODE>i386</CODE>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC51" HREF="gdb_toc.html#TOC51">Examining Data</A></H1>
|
|
|
|
<P>
|
|
<A NAME="IDX241"></A>
|
|
<A NAME="IDX242"></A>
|
|
<A NAME="IDX243"></A>
|
|
<A NAME="IDX244"></A>
|
|
The usual way to examine data in your program is with the <CODE>print</CODE>
|
|
command (abbreviated <CODE>p</CODE>), or its synonym <CODE>inspect</CODE>.
|
|
It evaluates and prints the value of an expression of the language your
|
|
program is written in (see section <A HREF="gdb.html#SEC63">Using GDB with Different Languages</A>).
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>print <VAR>exp</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>print /<VAR>f</VAR> <VAR>exp</VAR></CODE>
|
|
<DD>
|
|
<VAR>exp</VAR> is an expression (in the source language). By default the
|
|
value of <VAR>exp</VAR> is printed in a format appropriate to its data type;
|
|
you can choose a different format by specifying <SAMP>`/<VAR>f</VAR>'</SAMP>, where
|
|
<VAR>f</VAR> is a letter specifying the format; see section <A HREF="gdb.html#SEC55">Output formats</A>.
|
|
|
|
<DT><CODE>print</CODE>
|
|
<DD>
|
|
<DT><CODE>print /<VAR>f</VAR></CODE>
|
|
<DD>
|
|
If you omit <VAR>exp</VAR>, GDB displays the last value again (from the
|
|
<STRONG>value history</STRONG>; see section <A HREF="gdb.html#SEC59">Value history</A>). This allows you to
|
|
conveniently inspect the same value in an alternative format.
|
|
</DL>
|
|
|
|
<P>
|
|
A more low-level way of examining data is with the <CODE>x</CODE> command.
|
|
It examines data in memory at a specified address and prints it in a
|
|
specified format. See section <A HREF="gdb.html#SEC56">Examining memory</A>.
|
|
|
|
</P>
|
|
<P>
|
|
If you are interested in information about types, or about how the fields
|
|
of a struct
|
|
or class
|
|
are declared, use the <CODE>ptype <VAR>exp</VAR></CODE>
|
|
command rather than <CODE>print</CODE>. See section <A HREF="gdb.html#SEC90">Examining the Symbol Table</A>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC52" HREF="gdb_toc.html#TOC52">Expressions</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX245"></A>
|
|
<CODE>print</CODE> and many other GDB commands accept an expression and
|
|
compute its value. Any kind of constant, variable or operator defined
|
|
by the programming language you are using is valid in an expression in
|
|
GDB. This includes conditional expressions, function calls, casts
|
|
and string constants. It unfortunately does not include symbols defined
|
|
by preprocessor <CODE>#define</CODE> commands.
|
|
|
|
</P>
|
|
<P>
|
|
GDB now supports array constants in expressions input by
|
|
the user. The syntax is <VAR>{element, element...}</VAR>. For example,
|
|
you can now use the command <CODE>print {1, 2, 3}</CODE> to build up an array in
|
|
memory that is malloc'd in the target program.
|
|
|
|
</P>
|
|
<P>
|
|
Because C is so widespread, most of the expressions shown in examples in
|
|
this manual are in C. See section <A HREF="gdb.html#SEC63">Using GDB with Different Languages</A>, for information on how to use expressions in other
|
|
languages.
|
|
|
|
</P>
|
|
<P>
|
|
In this section, we discuss operators that you can use in GDB
|
|
expressions regardless of your programming language.
|
|
|
|
</P>
|
|
<P>
|
|
Casts are supported in all languages, not just in C, because it is so
|
|
useful to cast a number into a pointer in order to examine a structure
|
|
at that address in memory.
|
|
|
|
</P>
|
|
<P>
|
|
GDB supports these operators, in addition to those common
|
|
to programming languages:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>@</CODE>
|
|
<DD>
|
|
<SAMP>`@'</SAMP> is a binary operator for treating parts of memory as arrays.
|
|
See section <A HREF="gdb.html#SEC54">Artificial arrays</A>, for more information.
|
|
|
|
<DT><CODE>::</CODE>
|
|
<DD>
|
|
<SAMP>`::'</SAMP> allows you to specify a variable in terms of the file or
|
|
function where it is defined. See section <A HREF="gdb.html#SEC53">Program variables</A>.
|
|
|
|
<A NAME="IDX246"></A>
|
|
<A NAME="IDX247"></A>
|
|
<A NAME="IDX248"></A>
|
|
<A NAME="IDX249"></A>
|
|
<DT><CODE>{<VAR>type</VAR>} <VAR>addr</VAR></CODE>
|
|
<DD>
|
|
Refers to an object of type <VAR>type</VAR> stored at address <VAR>addr</VAR> in
|
|
memory. <VAR>addr</VAR> may be any expression whose value is an integer or
|
|
pointer (but parentheses are required around binary operators, just as in
|
|
a cast). This construct is allowed regardless of what kind of data is
|
|
normally supposed to reside at <VAR>addr</VAR>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC53" HREF="gdb_toc.html#TOC53">Program variables</A></H2>
|
|
|
|
<P>
|
|
The most common kind of expression to use is the name of a variable
|
|
in your program.
|
|
|
|
</P>
|
|
<P>
|
|
Variables in expressions are understood in the selected stack frame
|
|
(see section <A HREF="gdb.html#SEC43">Selecting a frame</A>); they must be either:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
global (or static)
|
|
</UL>
|
|
|
|
<P>
|
|
or
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
visible according to the scope rules of the
|
|
programming language from the point of execution in that frame
|
|
</UL>
|
|
|
|
<P>
|
|
This means that in the function
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo (a)
|
|
int a;
|
|
{
|
|
bar (a);
|
|
{
|
|
int b = test ();
|
|
bar (b);
|
|
}
|
|
}
|
|
</PRE>
|
|
|
|
<P>
|
|
you can examine and use the variable <CODE>a</CODE> whenever your program is
|
|
executing within the function <CODE>foo</CODE>, but you can only use or
|
|
examine the variable <CODE>b</CODE> while your program is executing inside
|
|
the block where <CODE>b</CODE> is declared.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX250"></A>
|
|
There is an exception: you can refer to a variable or function whose
|
|
scope is a single source file even if the current execution point is not
|
|
in this file. But it is possible to have more than one such variable or
|
|
function with the same name (in different source files). If that
|
|
happens, referring to that name has unpredictable effects. If you wish,
|
|
you can specify a static variable in a particular function or file,
|
|
using the colon-colon notation:
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX251"></A>
|
|
<A NAME="IDX252"></A>
|
|
|
|
<PRE>
|
|
<VAR>file</VAR>::<VAR>variable</VAR>
|
|
<VAR>function</VAR>::<VAR>variable</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
Here <VAR>file</VAR> or <VAR>function</VAR> is the name of the context for the
|
|
static <VAR>variable</VAR>. In the case of file names, you can use quotes to
|
|
make sure GDB parses the file name as a single word--for example,
|
|
to print a global value of <CODE>x</CODE> defined in <TT>`f2.c'</TT>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) p 'f2.c'::x
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX253"></A>
|
|
This use of <SAMP>`::'</SAMP> is very rarely in conflict with the very similar
|
|
use of the same notation in C++. GDB also supports use of the C++
|
|
scope resolution operator in GDB expressions.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX254"></A>
|
|
<A NAME="IDX255"></A>
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> Occasionally, a local variable may appear to have the
|
|
wrong value at certain points in a function--just after entry to a new
|
|
scope, and just before exit.
|
|
</BLOCKQUOTE>
|
|
|
|
<P>
|
|
You may see this problem when you are stepping by machine instructions.
|
|
This is because, on most machines, it takes more than one instruction to
|
|
set up a stack frame (including local variable definitions); if you are
|
|
stepping by machine instructions, variables may appear to have the wrong
|
|
values until the stack frame is completely built. On exit, it usually
|
|
also takes more than one machine instruction to destroy a stack frame;
|
|
after you begin stepping through that group of instructions, local
|
|
variable definitions may be gone.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC54" HREF="gdb_toc.html#TOC54">Artificial arrays</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX256"></A>
|
|
<A NAME="IDX257"></A>
|
|
It is often useful to print out several successive objects of the
|
|
same type in memory; a section of an array, or an array of
|
|
dynamically determined size for which only a pointer exists in the
|
|
program.
|
|
|
|
</P>
|
|
<P>
|
|
You can do this by referring to a contiguous span of memory as an
|
|
<STRONG>artificial array</STRONG>, using the binary operator <SAMP>`@'</SAMP>. The left
|
|
operand of <SAMP>`@'</SAMP> should be the first element of the desired array
|
|
and be an individual object. The right operand should be the desired length
|
|
of the array. The result is an array value whose elements are all of
|
|
the type of the left argument. The first element is actually the left
|
|
argument; the second element comes from bytes of memory immediately
|
|
following those that hold the first element, and so on. Here is an
|
|
example. If a program says
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
int *array = (int *) malloc (len * sizeof (int));
|
|
</PRE>
|
|
|
|
<P>
|
|
you can print the contents of <CODE>array</CODE> with
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
p *array@len
|
|
</PRE>
|
|
|
|
<P>
|
|
The left operand of <SAMP>`@'</SAMP> must reside in memory. Array values made
|
|
with <SAMP>`@'</SAMP> in this way behave just like other arrays in terms of
|
|
subscripting, and are coerced to pointers when used in expressions.
|
|
Artificial arrays most often appear in expressions via the value history
|
|
(see section <A HREF="gdb.html#SEC59">Value history</A>), after printing one out.
|
|
|
|
</P>
|
|
<P>
|
|
Another way to create an artificial array is to use a cast.
|
|
This re-interprets a value as if it were an array.
|
|
The value need not be in memory:
|
|
|
|
<PRE>
|
|
(gdb) p/x (short[2])0x12345678
|
|
$1 = {0x1234, 0x5678}
|
|
</PRE>
|
|
|
|
<P>
|
|
As a convenience, if you leave the array length out (as in
|
|
<SAMP>`(<VAR>type</VAR>)[])<VAR>value</VAR>'</SAMP>) gdb calculates the size to fill
|
|
the value (as <SAMP>`sizeof(<VAR>value</VAR>)/sizeof(<VAR>type</VAR>)'</SAMP>:
|
|
|
|
<PRE>
|
|
(gdb) p/x (short[])0x12345678
|
|
$2 = {0x1234, 0x5678}
|
|
</PRE>
|
|
|
|
<P>
|
|
Sometimes the artificial array mechanism is not quite enough; in
|
|
moderately complex data structures, the elements of interest may not
|
|
actually be adjacent--for example, if you are interested in the values
|
|
of pointers in an array. One useful work-around in this situation is
|
|
to use a convenience variable (see section <A HREF="gdb.html#SEC60">Convenience variables</A>) as a counter in an expression that prints the first
|
|
interesting value, and then repeat that expression via <KBD>RET</KBD>. For
|
|
instance, suppose you have an array <CODE>dtab</CODE> of pointers to
|
|
structures, and you are interested in the values of a field <CODE>fv</CODE>
|
|
in each structure. Here is an example of what you might type:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
set $i = 0
|
|
p dtab[$i++]->fv
|
|
<KBD>RET</KBD>
|
|
<KBD>RET</KBD>
|
|
...
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC55" HREF="gdb_toc.html#TOC55">Output formats</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX258"></A>
|
|
<A NAME="IDX259"></A>
|
|
By default, GDB prints a value according to its data type. Sometimes
|
|
this is not what you want. For example, you might want to print a number
|
|
in hex, or a pointer in decimal. Or you might want to view data in memory
|
|
at a certain address as a character string or as an instruction. To do
|
|
these things, specify an <STRONG>output format</STRONG> when you print a value.
|
|
|
|
</P>
|
|
<P>
|
|
The simplest use of output formats is to say how to print a value
|
|
already computed. This is done by starting the arguments of the
|
|
<CODE>print</CODE> command with a slash and a format letter. The format
|
|
letters supported are:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>x</CODE>
|
|
<DD>
|
|
Regard the bits of the value as an integer, and print the integer in
|
|
hexadecimal.
|
|
|
|
<DT><CODE>d</CODE>
|
|
<DD>
|
|
Print as integer in signed decimal.
|
|
|
|
<DT><CODE>u</CODE>
|
|
<DD>
|
|
Print as integer in unsigned decimal.
|
|
|
|
<DT><CODE>o</CODE>
|
|
<DD>
|
|
Print as integer in octal.
|
|
|
|
<DT><CODE>t</CODE>
|
|
<DD>
|
|
Print as integer in binary. The letter <SAMP>`t'</SAMP> stands for "two".
|
|
<A NAME="DOCF1" HREF="gdb_foot.html#FOOT1">(1)</A>
|
|
|
|
<DT><CODE>a</CODE>
|
|
<DD>
|
|
<A NAME="IDX260"></A>
|
|
Print as an address, both absolute in hexadecimal and as an offset from
|
|
the nearest preceding symbol. You can use this format used to discover
|
|
where (in what function) an unknown address is located:
|
|
|
|
|
|
<PRE>
|
|
(gdb) p/a 0x54320
|
|
$3 = 0x54320 <_initialize_vx+396>
|
|
</PRE>
|
|
|
|
<DT><CODE>c</CODE>
|
|
<DD>
|
|
Regard as an integer and print it as a character constant.
|
|
|
|
<DT><CODE>f</CODE>
|
|
<DD>
|
|
Regard the bits of the value as a floating point number and print
|
|
using typical floating point syntax.
|
|
</DL>
|
|
|
|
<P>
|
|
For example, to print the program counter in hex (see section <A HREF="gdb.html#SEC61">Registers</A>), type
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
p/x $pc
|
|
</PRE>
|
|
|
|
<P>
|
|
Note that no space is required before the slash; this is because command
|
|
names in GDB cannot contain a slash.
|
|
|
|
</P>
|
|
<P>
|
|
To reprint the last value in the value history with a different format,
|
|
you can use the <CODE>print</CODE> command with just a format and no
|
|
expression. For example, <SAMP>`p/x'</SAMP> reprints the last value in hex.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC56" HREF="gdb_toc.html#TOC56">Examining memory</A></H2>
|
|
|
|
<P>
|
|
You can use the command <CODE>x</CODE> (for "examine") to examine memory in
|
|
any of several formats, independently of your program's data types.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX261"></A>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>x/<VAR>nfu</VAR> <VAR>addr</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX262"></A>
|
|
|
|
<DT><CODE>x <VAR>addr</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>x</CODE>
|
|
<DD>
|
|
Use the <CODE>x</CODE> command to examine memory.
|
|
</DL>
|
|
|
|
<P>
|
|
<VAR>n</VAR>, <VAR>f</VAR>, and <VAR>u</VAR> are all optional parameters that specify how
|
|
much memory to display and how to format it; <VAR>addr</VAR> is an
|
|
expression giving the address where you want to start displaying memory.
|
|
If you use defaults for <VAR>nfu</VAR>, you need not type the slash <SAMP>`/'</SAMP>.
|
|
Several commands set convenient defaults for <VAR>addr</VAR>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><VAR>n</VAR>, the repeat count
|
|
<DD>
|
|
The repeat count is a decimal integer; the default is 1. It specifies
|
|
how much memory (counting by units <VAR>u</VAR>) to display.
|
|
|
|
<DT><VAR>f</VAR>, the display format
|
|
<DD>
|
|
The display format is one of the formats used by <CODE>print</CODE>,
|
|
<SAMP>`s'</SAMP> (null-terminated string), or <SAMP>`i'</SAMP> (machine instruction).
|
|
The default is <SAMP>`x'</SAMP> (hexadecimal) initially.
|
|
The default changes each time you use either <CODE>x</CODE> or <CODE>print</CODE>.
|
|
|
|
<DT><VAR>u</VAR>, the unit size
|
|
<DD>
|
|
The unit size is any of
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>b</CODE>
|
|
<DD>
|
|
Bytes.
|
|
<DT><CODE>h</CODE>
|
|
<DD>
|
|
Halfwords (two bytes).
|
|
<DT><CODE>w</CODE>
|
|
<DD>
|
|
Words (four bytes). This is the initial default.
|
|
<DT><CODE>g</CODE>
|
|
<DD>
|
|
Giant words (eight bytes).
|
|
</DL>
|
|
|
|
Each time you specify a unit size with <CODE>x</CODE>, that size becomes the
|
|
default unit the next time you use <CODE>x</CODE>. (For the <SAMP>`s'</SAMP> and
|
|
<SAMP>`i'</SAMP> formats, the unit size is ignored and is normally not written.)
|
|
|
|
<DT><VAR>addr</VAR>, starting display address
|
|
<DD>
|
|
<VAR>addr</VAR> is the address where you want GDB to begin displaying
|
|
memory. The expression need not have a pointer value (though it may);
|
|
it is always interpreted as an integer address of a byte of memory.
|
|
See section <A HREF="gdb.html#SEC52">Expressions</A>, for more information on expressions. The default for
|
|
<VAR>addr</VAR> is usually just after the last address examined--but several
|
|
other commands also set the default address: <CODE>info breakpoints</CODE> (to
|
|
the address of the last breakpoint listed), <CODE>info line</CODE> (to the
|
|
starting address of a line), and <CODE>print</CODE> (if you use it to display
|
|
a value from memory).
|
|
</DL>
|
|
|
|
<P>
|
|
For example, <SAMP>`x/3uh 0x54320'</SAMP> is a request to display three halfwords
|
|
(<CODE>h</CODE>) of memory, formatted as unsigned decimal integers (<SAMP>`u'</SAMP>),
|
|
starting at address <CODE>0x54320</CODE>. <SAMP>`x/4xw $sp'</SAMP> prints the four
|
|
words (<SAMP>`w'</SAMP>) of memory above the stack pointer (here, <SAMP>`$sp'</SAMP>;
|
|
see section <A HREF="gdb.html#SEC61">Registers</A>) in hexadecimal (<SAMP>`x'</SAMP>).
|
|
|
|
</P>
|
|
<P>
|
|
Since the letters indicating unit sizes are all distinct from the
|
|
letters specifying output formats, you do not have to remember whether
|
|
unit size or format comes first; either order works. The output
|
|
specifications <SAMP>`4xw'</SAMP> and <SAMP>`4wx'</SAMP> mean exactly the same thing.
|
|
(However, the count <VAR>n</VAR> must come first; <SAMP>`wx4'</SAMP> does not work.)
|
|
|
|
</P>
|
|
<P>
|
|
Even though the unit size <VAR>u</VAR> is ignored for the formats <SAMP>`s'</SAMP>
|
|
and <SAMP>`i'</SAMP>, you might still want to use a count <VAR>n</VAR>; for example,
|
|
<SAMP>`3i'</SAMP> specifies that you want to see three machine instructions,
|
|
including any operands. The command <CODE>disassemble</CODE> gives an
|
|
alternative way of inspecting machine instructions; see section <A HREF="gdb.html#SEC50">Source and machine code</A>.
|
|
|
|
</P>
|
|
<P>
|
|
All the defaults for the arguments to <CODE>x</CODE> are designed to make it
|
|
easy to continue scanning memory with minimal specifications each time
|
|
you use <CODE>x</CODE>. For example, after you have inspected three machine
|
|
instructions with <SAMP>`x/3i <VAR>addr</VAR>'</SAMP>, you can inspect the next seven
|
|
with just <SAMP>`x/7'</SAMP>. If you use <KBD>RET</KBD> to repeat the <CODE>x</CODE> command,
|
|
the repeat count <VAR>n</VAR> is used again; the other arguments default as
|
|
for successive uses of <CODE>x</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX263"></A>
|
|
The addresses and contents printed by the <CODE>x</CODE> command are not saved
|
|
in the value history because there is often too much of them and they
|
|
would get in the way. Instead, GDB makes these values available for
|
|
subsequent use in expressions as values of the convenience variables
|
|
<CODE>$_</CODE> and <CODE>$__</CODE>. After an <CODE>x</CODE> command, the last address
|
|
examined is available for use in expressions in the convenience variable
|
|
<CODE>$_</CODE>. The contents of that address, as examined, are available in
|
|
the convenience variable <CODE>$__</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
If the <CODE>x</CODE> command has a repeat count, the address and contents saved
|
|
are from the last memory unit printed; this is not the same as the last
|
|
address printed if several units were printed on the last line of output.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC57" HREF="gdb_toc.html#TOC57">Automatic display</A></H2>
|
|
<P>
|
|
<A NAME="IDX264"></A>
|
|
<A NAME="IDX265"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If you find that you want to print the value of an expression frequently
|
|
(to see how it changes), you might want to add it to the <STRONG>automatic
|
|
display list</STRONG> so that GDB prints its value each time your program stops.
|
|
Each expression added to the list is given a number to identify it;
|
|
to remove an expression from the list, you specify that number.
|
|
The automatic display looks like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
2: foo = 38
|
|
3: bar[5] = (struct hack *) 0x3804
|
|
</PRE>
|
|
|
|
<P>
|
|
This display shows item numbers, expressions and their current values. As with
|
|
displays you request manually using <CODE>x</CODE> or <CODE>print</CODE>, you can
|
|
specify the output format you prefer; in fact, <CODE>display</CODE> decides
|
|
whether to use <CODE>print</CODE> or <CODE>x</CODE> depending on how elaborate your
|
|
format specification is--it uses <CODE>x</CODE> if you specify a unit size,
|
|
or one of the two formats (<SAMP>`i'</SAMP> and <SAMP>`s'</SAMP>) that are only
|
|
supported by <CODE>x</CODE>; otherwise it uses <CODE>print</CODE>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>display <VAR>exp</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX266"></A>
|
|
|
|
Add the expression <VAR>exp</VAR> to the list of expressions to display
|
|
each time your program stops. See section <A HREF="gdb.html#SEC52">Expressions</A>.
|
|
|
|
<CODE>display</CODE> does not repeat if you press <KBD>RET</KBD> again after using it.
|
|
|
|
<DT><CODE>display/<VAR>fmt</VAR> <VAR>exp</VAR></CODE>
|
|
<DD>
|
|
For <VAR>fmt</VAR> specifying only a display format and not a size or
|
|
count, add the expression <VAR>exp</VAR> to the auto-display list but
|
|
arrange to display it each time in the specified format <VAR>fmt</VAR>.
|
|
See section <A HREF="gdb.html#SEC55">Output formats</A>.
|
|
|
|
<DT><CODE>display/<VAR>fmt</VAR> <VAR>addr</VAR></CODE>
|
|
<DD>
|
|
For <VAR>fmt</VAR> <SAMP>`i'</SAMP> or <SAMP>`s'</SAMP>, or including a unit-size or a
|
|
number of units, add the expression <VAR>addr</VAR> as a memory address to
|
|
be examined each time your program stops. Examining means in effect
|
|
doing <SAMP>`x/<VAR>fmt</VAR> <VAR>addr</VAR>'</SAMP>. See section <A HREF="gdb.html#SEC56">Examining memory</A>.
|
|
</DL>
|
|
|
|
<P>
|
|
For example, <SAMP>`display/i $pc'</SAMP> can be helpful, to see the machine
|
|
instruction about to be executed each time execution stops (<SAMP>`$pc'</SAMP>
|
|
is a common name for the program counter; see section <A HREF="gdb.html#SEC61">Registers</A>).
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>undisplay <VAR>dnums</VAR>...</CODE>
|
|
<DD>
|
|
<A NAME="IDX267"></A>
|
|
<A NAME="IDX268"></A>
|
|
|
|
<DT><CODE>delete display <VAR>dnums</VAR>...</CODE>
|
|
<DD>
|
|
Remove item numbers <VAR>dnums</VAR> from the list of expressions to display.
|
|
|
|
<CODE>undisplay</CODE> does not repeat if you press <KBD>RET</KBD> after using it.
|
|
(Otherwise you would just get the error <SAMP>`No display number ...'</SAMP>.)
|
|
|
|
<A NAME="IDX269"></A>
|
|
<DT><CODE>disable display <VAR>dnums</VAR>...</CODE>
|
|
<DD>
|
|
Disable the display of item numbers <VAR>dnums</VAR>. A disabled display
|
|
item is not printed automatically, but is not forgotten. It may be
|
|
enabled again later.
|
|
|
|
<A NAME="IDX270"></A>
|
|
<DT><CODE>enable display <VAR>dnums</VAR>...</CODE>
|
|
<DD>
|
|
Enable display of item numbers <VAR>dnums</VAR>. It becomes effective once
|
|
again in auto display of its expression, until you specify otherwise.
|
|
|
|
<DT><CODE>display</CODE>
|
|
<DD>
|
|
Display the current values of the expressions on the list, just as is
|
|
done when your program stops.
|
|
|
|
<A NAME="IDX271"></A>
|
|
<DT><CODE>info display</CODE>
|
|
<DD>
|
|
Print the list of expressions previously set up to display
|
|
automatically, each one with its item number, but without showing the
|
|
values. This includes disabled expressions, which are marked as such.
|
|
It also includes expressions which would not be displayed right now
|
|
because they refer to automatic variables not currently available.
|
|
</DL>
|
|
|
|
<P>
|
|
If a display expression refers to local variables, then it does not make
|
|
sense outside the lexical context for which it was set up. Such an
|
|
expression is disabled when execution enters a context where one of its
|
|
variables is not defined. For example, if you give the command
|
|
<CODE>display last_char</CODE> while inside a function with an argument
|
|
<CODE>last_char</CODE>, GDB displays this argument while your program
|
|
continues to stop inside that function. When it stops elsewhere--where
|
|
there is no variable <CODE>last_char</CODE>---the display is disabled
|
|
automatically. The next time your program stops where <CODE>last_char</CODE>
|
|
is meaningful, you can enable the display expression once again.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC58" HREF="gdb_toc.html#TOC58">Print settings</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX272"></A>
|
|
<A NAME="IDX273"></A>
|
|
GDB provides the following ways to control how arrays, structures,
|
|
and symbols are printed.
|
|
|
|
</P>
|
|
<P>
|
|
These settings are useful for debugging programs in any language:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set print address</CODE>
|
|
<DD>
|
|
<A NAME="IDX274"></A>
|
|
|
|
<DT><CODE>set print address on</CODE>
|
|
<DD>
|
|
GDB prints memory addresses showing the location of stack
|
|
traces, structure values, pointer values, breakpoints, and so forth,
|
|
even when it also displays the contents of those addresses. The default
|
|
is <CODE>on</CODE>. For example, this is what a stack frame display looks like with
|
|
<CODE>set print address on</CODE>:
|
|
|
|
|
|
<PRE>
|
|
(gdb) f
|
|
#0 set_quotes (lq=0x34c78 "<<", rq=0x34c88 ">>")
|
|
at input.c:530
|
|
530 if (lquote != def_lquote)
|
|
</PRE>
|
|
|
|
<DT><CODE>set print address off</CODE>
|
|
<DD>
|
|
Do not print addresses when displaying their contents. For example,
|
|
this is the same stack frame displayed with <CODE>set print address off</CODE>:
|
|
|
|
|
|
<PRE>
|
|
(gdb) set print addr off
|
|
(gdb) f
|
|
#0 set_quotes (lq="<<", rq=">>") at input.c:530
|
|
530 if (lquote != def_lquote)
|
|
</PRE>
|
|
|
|
You can use <SAMP>`set print address off'</SAMP> to eliminate all machine
|
|
dependent displays from the GDB interface. For example, with
|
|
<CODE>print address off</CODE>, you should get the same text for backtraces on
|
|
all machines--whether or not they involve pointer arguments.
|
|
|
|
<A NAME="IDX275"></A>
|
|
<DT><CODE>show print address</CODE>
|
|
<DD>
|
|
Show whether or not addresses are to be printed.
|
|
</DL>
|
|
|
|
<P>
|
|
When GDB prints a symbolic address, it normally prints the
|
|
closest earlier symbol plus an offset. If that symbol does not uniquely
|
|
identify the address (for example, it is a name whose scope is a single
|
|
source file), you may need to clarify. One way to do this is with
|
|
<CODE>info line</CODE>, for example <SAMP>`info line *0x4537'</SAMP>. Alternately,
|
|
you can set GDB to print the source file and line number when
|
|
it prints a symbolic address:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set print symbol-filename on</CODE>
|
|
<DD>
|
|
<A NAME="IDX276"></A>
|
|
|
|
Tell GDB to print the source file name and line number of a
|
|
symbol in the symbolic form of an address.
|
|
|
|
<DT><CODE>set print symbol-filename off</CODE>
|
|
<DD>
|
|
Do not print source file name and line number of a symbol. This is the
|
|
default.
|
|
|
|
<A NAME="IDX277"></A>
|
|
<DT><CODE>show print symbol-filename</CODE>
|
|
<DD>
|
|
Show whether or not GDB will print the source file name and
|
|
line number of a symbol in the symbolic form of an address.
|
|
</DL>
|
|
|
|
<P>
|
|
Another situation where it is helpful to show symbol filenames and line
|
|
numbers is when disassembling code; GDB shows you the line
|
|
number and source file that corresponds to each instruction.
|
|
|
|
</P>
|
|
<P>
|
|
Also, you may wish to see the symbolic form only if the address being
|
|
printed is reasonably close to the closest earlier symbol:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set print max-symbolic-offset <VAR>max-offset</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX278"></A>
|
|
|
|
Tell GDB to only display the symbolic form of an address if the
|
|
offset between the closest earlier symbol and the address is less than
|
|
<VAR>max-offset</VAR>. The default is 0, which tells GDB
|
|
to always print the symbolic form of an address if any symbol precedes it.
|
|
|
|
<A NAME="IDX279"></A>
|
|
<DT><CODE>show print max-symbolic-offset</CODE>
|
|
<DD>
|
|
Ask how large the maximum offset is that GDB prints in a
|
|
symbolic address.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX280"></A>
|
|
<A NAME="IDX281"></A>
|
|
If you have a pointer and you are not sure where it points, try
|
|
<SAMP>`set print symbol-filename on'</SAMP>. Then you can determine the name
|
|
and source file location of the variable where it points, using
|
|
<SAMP>`p/a <VAR>pointer</VAR>'</SAMP>. This interprets the address in symbolic form.
|
|
For example, here GDB shows that a variable <CODE>ptt</CODE> points
|
|
at another variable <CODE>t</CODE>, defined in <TT>`hi2.c'</TT>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) set print symbol-filename on
|
|
(gdb) p/a ptt
|
|
$4 = 0xe008 <t in hi2.c>
|
|
</PRE>
|
|
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> For pointers that point to a local variable, <SAMP>`p/a'</SAMP>
|
|
does not show the symbol name and filename of the referent, even with
|
|
the appropriate <CODE>set print</CODE> options turned on.
|
|
</BLOCKQUOTE>
|
|
|
|
<P>
|
|
Other settings control how different kinds of objects are printed:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set print array</CODE>
|
|
<DD>
|
|
<A NAME="IDX282"></A>
|
|
|
|
<DT><CODE>set print array on</CODE>
|
|
<DD>
|
|
Pretty print arrays. This format is more convenient to read,
|
|
but uses more space. The default is off.
|
|
|
|
<DT><CODE>set print array off</CODE>
|
|
<DD>
|
|
Return to compressed format for arrays.
|
|
|
|
<A NAME="IDX283"></A>
|
|
<DT><CODE>show print array</CODE>
|
|
<DD>
|
|
Show whether compressed or pretty format is selected for displaying
|
|
arrays.
|
|
|
|
<A NAME="IDX284"></A>
|
|
<DT><CODE>set print elements <VAR>number-of-elements</VAR></CODE>
|
|
<DD>
|
|
Set a limit on how many elements of an array GDB will print.
|
|
If GDB is printing a large array, it stops printing after it has
|
|
printed the number of elements set by the <CODE>set print elements</CODE> command.
|
|
This limit also applies to the display of strings.
|
|
Setting <VAR>number-of-elements</VAR> to zero means that the printing is unlimited.
|
|
|
|
<A NAME="IDX285"></A>
|
|
<DT><CODE>show print elements</CODE>
|
|
<DD>
|
|
Display the number of elements of a large array that GDB will print.
|
|
If the number is 0, then the printing is unlimited.
|
|
|
|
<A NAME="IDX286"></A>
|
|
<DT><CODE>set print null-stop</CODE>
|
|
<DD>
|
|
Cause GDB to stop printing the characters of an array when the first
|
|
NULL is encountered. This is useful when large arrays actually
|
|
contain only short strings.
|
|
|
|
<A NAME="IDX287"></A>
|
|
<DT><CODE>set print pretty on</CODE>
|
|
<DD>
|
|
Cause GDB to print structures in an indented format with one member
|
|
per line, like this:
|
|
|
|
|
|
<PRE>
|
|
$1 = {
|
|
next = 0x0,
|
|
flags = {
|
|
sweet = 1,
|
|
sour = 1
|
|
},
|
|
meat = 0x54 "Pork"
|
|
}
|
|
</PRE>
|
|
|
|
<DT><CODE>set print pretty off</CODE>
|
|
<DD>
|
|
Cause GDB to print structures in a compact format, like this:
|
|
|
|
|
|
<PRE>
|
|
$1 = {next = 0x0, flags = {sweet = 1, sour = 1}, \
|
|
meat = 0x54 "Pork"}
|
|
</PRE>
|
|
|
|
This is the default format.
|
|
|
|
<A NAME="IDX288"></A>
|
|
<DT><CODE>show print pretty</CODE>
|
|
<DD>
|
|
Show which format GDB is using to print structures.
|
|
|
|
<A NAME="IDX289"></A>
|
|
<DT><CODE>set print sevenbit-strings on</CODE>
|
|
<DD>
|
|
Print using only seven-bit characters; if this option is set,
|
|
GDB displays any eight-bit characters (in strings or
|
|
character values) using the notation <CODE>\</CODE><VAR>nnn</VAR>. This setting is
|
|
best if you are working in English (ASCII) and you use the
|
|
high-order bit of characters as a marker or "meta" bit.
|
|
|
|
<DT><CODE>set print sevenbit-strings off</CODE>
|
|
<DD>
|
|
Print full eight-bit characters. This allows the use of more
|
|
international character sets, and is the default.
|
|
|
|
<A NAME="IDX290"></A>
|
|
<DT><CODE>show print sevenbit-strings</CODE>
|
|
<DD>
|
|
Show whether or not GDB is printing only seven-bit characters.
|
|
|
|
<A NAME="IDX291"></A>
|
|
<DT><CODE>set print union on</CODE>
|
|
<DD>
|
|
Tell GDB to print unions which are contained in structures. This
|
|
is the default setting.
|
|
|
|
<DT><CODE>set print union off</CODE>
|
|
<DD>
|
|
Tell GDB not to print unions which are contained in structures.
|
|
|
|
<A NAME="IDX292"></A>
|
|
<DT><CODE>show print union</CODE>
|
|
<DD>
|
|
Ask GDB whether or not it will print unions which are contained in
|
|
structures.
|
|
|
|
For example, given the declarations
|
|
|
|
|
|
<PRE>
|
|
typedef enum {Tree, Bug} Species;
|
|
typedef enum {Big_tree, Acorn, Seedling} Tree_forms;
|
|
typedef enum {Caterpillar, Cocoon, Butterfly}
|
|
Bug_forms;
|
|
|
|
struct thing {
|
|
Species it;
|
|
union {
|
|
Tree_forms tree;
|
|
Bug_forms bug;
|
|
} form;
|
|
};
|
|
|
|
struct thing foo = {Tree, {Acorn}};
|
|
</PRE>
|
|
|
|
with <CODE>set print union on</CODE> in effect <SAMP>`p foo'</SAMP> would print
|
|
|
|
|
|
<PRE>
|
|
$1 = {it = Tree, form = {tree = Acorn, bug = Cocoon}}
|
|
</PRE>
|
|
|
|
and with <CODE>set print union off</CODE> in effect it would print
|
|
|
|
|
|
<PRE>
|
|
$1 = {it = Tree, form = {...}}
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
These settings are of interest when debugging C++ programs:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set print demangle</CODE>
|
|
<DD>
|
|
<A NAME="IDX293"></A>
|
|
<A NAME="IDX294"></A>
|
|
|
|
<DT><CODE>set print demangle on</CODE>
|
|
<DD>
|
|
Print C++ names in their source form rather than in the encoded
|
|
("mangled") form passed to the assembler and linker for type-safe
|
|
linkage. The default is <SAMP>`on'</SAMP>.
|
|
|
|
<A NAME="IDX295"></A>
|
|
<DT><CODE>show print demangle</CODE>
|
|
<DD>
|
|
Show whether C++ names are printed in mangled or demangled form.
|
|
|
|
<A NAME="IDX296"></A>
|
|
<DT><CODE>set print asm-demangle</CODE>
|
|
<DD>
|
|
<DT><CODE>set print asm-demangle on</CODE>
|
|
<DD>
|
|
Print C++ names in their source form rather than their mangled form, even
|
|
in assembler code printouts such as instruction disassemblies.
|
|
The default is off.
|
|
|
|
<A NAME="IDX297"></A>
|
|
<DT><CODE>show print asm-demangle</CODE>
|
|
<DD>
|
|
Show whether C++ names in assembly listings are printed in mangled
|
|
or demangled form.
|
|
|
|
<A NAME="IDX298"></A>
|
|
<A NAME="IDX299"></A>
|
|
<A NAME="IDX300"></A>
|
|
<DT><CODE>set demangle-style <VAR>style</VAR></CODE>
|
|
<DD>
|
|
Choose among several encoding schemes used by different compilers to
|
|
represent C++ names. The choices for <VAR>style</VAR> are currently:
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>auto</CODE>
|
|
<DD>
|
|
Allow GDB to choose a decoding style by inspecting your program.
|
|
|
|
<DT><CODE>gnu</CODE>
|
|
<DD>
|
|
Decode based on the GNU C++ compiler (<CODE>g++</CODE>) encoding algorithm.
|
|
This is the default.
|
|
|
|
<DT><CODE>lucid</CODE>
|
|
<DD>
|
|
Decode based on the Lucid C++ compiler (<CODE>lcc</CODE>) encoding algorithm.
|
|
|
|
<DT><CODE>arm</CODE>
|
|
<DD>
|
|
Decode using the algorithm in the <CITE>C++ Annotated Reference Manual</CITE>.
|
|
<STRONG>Warning:</STRONG> this setting alone is not sufficient to allow
|
|
debugging <CODE>cfront</CODE>-generated executables. GDB would
|
|
require further enhancement to permit that.
|
|
|
|
<DT><CODE>foo</CODE>
|
|
<DD>
|
|
Show the list of formats.
|
|
</DL>
|
|
|
|
<A NAME="IDX301"></A>
|
|
<DT><CODE>show demangle-style</CODE>
|
|
<DD>
|
|
Display the encoding style currently in use for decoding C++ symbols.
|
|
|
|
<A NAME="IDX302"></A>
|
|
<DT><CODE>set print object</CODE>
|
|
<DD>
|
|
<DT><CODE>set print object on</CODE>
|
|
<DD>
|
|
When displaying a pointer to an object, identify the <EM>actual</EM>
|
|
(derived) type of the object rather than the <EM>declared</EM> type, using
|
|
the virtual function table.
|
|
|
|
<DT><CODE>set print object off</CODE>
|
|
<DD>
|
|
Display only the declared type of objects, without reference to the
|
|
virtual function table. This is the default setting.
|
|
|
|
<A NAME="IDX303"></A>
|
|
<DT><CODE>show print object</CODE>
|
|
<DD>
|
|
Show whether actual, or declared, object types are displayed.
|
|
|
|
<A NAME="IDX304"></A>
|
|
<DT><CODE>set print static-members</CODE>
|
|
<DD>
|
|
<DT><CODE>set print static-members on</CODE>
|
|
<DD>
|
|
Print static members when displaying a C++ object. The default is on.
|
|
|
|
<DT><CODE>set print static-members off</CODE>
|
|
<DD>
|
|
Do not print static members when displaying a C++ object.
|
|
|
|
<A NAME="IDX305"></A>
|
|
<DT><CODE>show print static-members</CODE>
|
|
<DD>
|
|
Show whether C++ static members are printed, or not.
|
|
|
|
<A NAME="IDX306"></A>
|
|
<DT><CODE>set print vtbl</CODE>
|
|
<DD>
|
|
<DT><CODE>set print vtbl on</CODE>
|
|
<DD>
|
|
Pretty print C++ virtual function tables. The default is off.
|
|
|
|
<DT><CODE>set print vtbl off</CODE>
|
|
<DD>
|
|
Do not pretty print C++ virtual function tables.
|
|
|
|
<A NAME="IDX307"></A>
|
|
<DT><CODE>show print vtbl</CODE>
|
|
<DD>
|
|
Show whether C++ virtual function tables are pretty printed, or not.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC59" HREF="gdb_toc.html#TOC59">Value history</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX308"></A>
|
|
Values printed by the <CODE>print</CODE> command are saved in the GDB
|
|
<STRONG>value history</STRONG>. This allows you to refer to them in other expressions.
|
|
Values are kept until the symbol table is re-read or discarded
|
|
(for example with the <CODE>file</CODE> or <CODE>symbol-file</CODE> commands).
|
|
When the symbol table changes, the value history is discarded,
|
|
since the values may contain pointers back to the types defined in the
|
|
symbol table.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX309"></A>
|
|
<A NAME="IDX310"></A>
|
|
<A NAME="IDX311"></A>
|
|
The values printed are given <STRONG>history numbers</STRONG> by which you can
|
|
refer to them. These are successive integers starting with one.
|
|
<CODE>print</CODE> shows you the history number assigned to a value by
|
|
printing <SAMP>`$<VAR>num</VAR> = '</SAMP> before the value; here <VAR>num</VAR> is the
|
|
history number.
|
|
|
|
</P>
|
|
<P>
|
|
To refer to any previous value, use <SAMP>`$'</SAMP> followed by the value's
|
|
history number. The way <CODE>print</CODE> labels its output is designed to
|
|
remind you of this. Just <CODE>$</CODE> refers to the most recent value in
|
|
the history, and <CODE>$$</CODE> refers to the value before that.
|
|
<CODE>$$<VAR>n</VAR></CODE> refers to the <VAR>n</VAR>th value from the end; <CODE>$$2</CODE>
|
|
is the value just prior to <CODE>$$</CODE>, <CODE>$$1</CODE> is equivalent to
|
|
<CODE>$$</CODE>, and <CODE>$$0</CODE> is equivalent to <CODE>$</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
For example, suppose you have just printed a pointer to a structure and
|
|
want to see the contents of the structure. It suffices to type
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
p *$
|
|
</PRE>
|
|
|
|
<P>
|
|
If you have a chain of structures where the component <CODE>next</CODE> points
|
|
to the next one, you can print the contents of the next one with this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
p *$.next
|
|
</PRE>
|
|
|
|
<P>
|
|
You can print successive links in the chain by repeating this
|
|
command--which you can do by just typing <KBD>RET</KBD>.
|
|
|
|
</P>
|
|
<P>
|
|
Note that the history records values, not expressions. If the value of
|
|
<CODE>x</CODE> is 4 and you type these commands:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
print x
|
|
set x=5
|
|
</PRE>
|
|
|
|
<P>
|
|
then the value recorded in the value history by the <CODE>print</CODE> command
|
|
remains 4 even though the value of <CODE>x</CODE> has changed.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>show values</CODE>
|
|
<DD>
|
|
<A NAME="IDX312"></A>
|
|
|
|
Print the last ten values in the value history, with their item numbers.
|
|
This is like <SAMP>`p $$9'</SAMP> repeated ten times, except that <CODE>show
|
|
values</CODE> does not change the history.
|
|
|
|
<DT><CODE>show values <VAR>n</VAR></CODE>
|
|
<DD>
|
|
Print ten history values centered on history item number <VAR>n</VAR>.
|
|
|
|
<DT><CODE>show values +</CODE>
|
|
<DD>
|
|
Print ten history values just after the values last printed. If no more
|
|
values are available, <CODE>show values +</CODE> produces no display.
|
|
</DL>
|
|
|
|
<P>
|
|
Pressing <KBD>RET</KBD> to repeat <CODE>show values <VAR>n</VAR></CODE> has exactly the
|
|
same effect as <SAMP>`show values +'</SAMP>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC60" HREF="gdb_toc.html#TOC60">Convenience variables</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX313"></A>
|
|
GDB provides <STRONG>convenience variables</STRONG> that you can use within
|
|
GDB to hold on to a value and refer to it later. These variables
|
|
exist entirely within GDB; they are not part of your program, and
|
|
setting a convenience variable has no direct effect on further execution
|
|
of your program. That is why you can use them freely.
|
|
|
|
</P>
|
|
<P>
|
|
Convenience variables are prefixed with <SAMP>`$'</SAMP>. Any name preceded by
|
|
<SAMP>`$'</SAMP> can be used for a convenience variable, unless it is one of
|
|
the predefined machine-specific register names (see section <A HREF="gdb.html#SEC61">Registers</A>).
|
|
(Value history references, in contrast, are <EM>numbers</EM> preceded
|
|
by <SAMP>`$'</SAMP>. See section <A HREF="gdb.html#SEC59">Value history</A>.)
|
|
|
|
</P>
|
|
<P>
|
|
You can save a value in a convenience variable with an assignment
|
|
expression, just as you would set a variable in your program.
|
|
For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
set $foo = *object_ptr
|
|
</PRE>
|
|
|
|
<P>
|
|
would save in <CODE>$foo</CODE> the value contained in the object pointed to by
|
|
<CODE>object_ptr</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
Using a convenience variable for the first time creates it, but its
|
|
value is <CODE>void</CODE> until you assign a new value. You can alter the
|
|
value with another assignment at any time.
|
|
|
|
</P>
|
|
<P>
|
|
Convenience variables have no fixed types. You can assign a convenience
|
|
variable any type of value, including structures and arrays, even if
|
|
that variable already has a value of a different type. The convenience
|
|
variable, when used as an expression, has the type of its current value.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>show convenience</CODE>
|
|
<DD>
|
|
<A NAME="IDX314"></A>
|
|
|
|
Print a list of convenience variables used so far, and their values.
|
|
Abbreviated <CODE>show con</CODE>.
|
|
</DL>
|
|
|
|
<P>
|
|
One of the ways to use a convenience variable is as a counter to be
|
|
incremented or a pointer to be advanced. For example, to print
|
|
a field from successive elements of an array of structures:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
set $i = 0
|
|
print bar[$i++]->contents
|
|
</PRE>
|
|
|
|
<P>
|
|
Repeat that command by typing <KBD>RET</KBD>.
|
|
|
|
</P>
|
|
<P>
|
|
Some convenience variables are created automatically by GDB and given
|
|
values likely to be useful.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>$_</CODE>
|
|
<DD>
|
|
<A NAME="IDX315"></A>
|
|
|
|
The variable <CODE>$_</CODE> is automatically set by the <CODE>x</CODE> command to
|
|
the last address examined (see section <A HREF="gdb.html#SEC56">Examining memory</A>). Other
|
|
commands which provide a default address for <CODE>x</CODE> to examine also
|
|
set <CODE>$_</CODE> to that address; these commands include <CODE>info line</CODE>
|
|
and <CODE>info breakpoint</CODE>. The type of <CODE>$_</CODE> is <CODE>void *</CODE>
|
|
except when set by the <CODE>x</CODE> command, in which case it is a pointer
|
|
to the type of <CODE>$__</CODE>.
|
|
|
|
<A NAME="IDX316"></A>
|
|
<DT><CODE>$__</CODE>
|
|
<DD>
|
|
The variable <CODE>$__</CODE> is automatically set by the <CODE>x</CODE> command
|
|
to the value found in the last address examined. Its type is chosen
|
|
to match the format in which the data was printed.
|
|
|
|
<DT><CODE>$_exitcode</CODE>
|
|
<DD>
|
|
<A NAME="IDX317"></A>
|
|
The variable <CODE>$_exitcode</CODE> is automatically set to the exit code when
|
|
the program being debugged terminates.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC61" HREF="gdb_toc.html#TOC61">Registers</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX318"></A>
|
|
You can refer to machine register contents, in expressions, as variables
|
|
with names starting with <SAMP>`$'</SAMP>. The names of registers are different
|
|
for each machine; use <CODE>info registers</CODE> to see the names used on
|
|
your machine.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info registers</CODE>
|
|
<DD>
|
|
<A NAME="IDX319"></A>
|
|
|
|
Print the names and values of all registers except floating-point
|
|
registers (in the selected stack frame).
|
|
|
|
<A NAME="IDX320"></A>
|
|
<A NAME="IDX321"></A>
|
|
<DT><CODE>info all-registers</CODE>
|
|
<DD>
|
|
Print the names and values of all registers, including floating-point
|
|
registers.
|
|
|
|
<DT><CODE>info registers <VAR>regname</VAR> ...</CODE>
|
|
<DD>
|
|
Print the <STRONG>relativized</STRONG> value of each specified register <VAR>regname</VAR>.
|
|
As discussed in detail below, register values are normally relative to
|
|
the selected stack frame. <VAR>regname</VAR> may be any register name valid on
|
|
the machine you are using, with or without the initial <SAMP>`$'</SAMP>.
|
|
</DL>
|
|
|
|
<P>
|
|
GDB has four "standard" register names that are available (in
|
|
expressions) on most machines--whenever they do not conflict with an
|
|
architecture's canonical mnemonics for registers. The register names
|
|
<CODE>$pc</CODE> and <CODE>$sp</CODE> are used for the program counter register and
|
|
the stack pointer. <CODE>$fp</CODE> is used for a register that contains a
|
|
pointer to the current stack frame, and <CODE>$ps</CODE> is used for a
|
|
register that contains the processor status. For example,
|
|
you could print the program counter in hex with
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
p/x $pc
|
|
</PRE>
|
|
|
|
<P>
|
|
or print the instruction to be executed next with
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
x/i $pc
|
|
</PRE>
|
|
|
|
<P>
|
|
or add four to the stack pointer<A NAME="DOCF2" HREF="gdb_foot.html#FOOT2">(2)</A> with
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
set $sp += 4
|
|
</PRE>
|
|
|
|
<P>
|
|
Whenever possible, these four standard register names are available on
|
|
your machine even though the machine has different canonical mnemonics,
|
|
so long as there is no conflict. The <CODE>info registers</CODE> command
|
|
shows the canonical names. For example, on the SPARC, <CODE>info
|
|
registers</CODE> displays the processor status register as <CODE>$psr</CODE> but you
|
|
can also refer to it as <CODE>$ps</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
GDB always considers the contents of an ordinary register as an
|
|
integer when the register is examined in this way. Some machines have
|
|
special registers which can hold nothing but floating point; these
|
|
registers are considered to have floating point values. There is no way
|
|
to refer to the contents of an ordinary register as floating point value
|
|
(although you can <EM>print</EM> it as a floating point value with
|
|
<SAMP>`print/f $<VAR>regname</VAR>'</SAMP>).
|
|
|
|
</P>
|
|
<P>
|
|
Some registers have distinct "raw" and "virtual" data formats. This
|
|
means that the data format in which the register contents are saved by
|
|
the operating system is not the same one that your program normally
|
|
sees. For example, the registers of the 68881 floating point
|
|
coprocessor are always saved in "extended" (raw) format, but all C
|
|
programs expect to work with "double" (virtual) format. In such
|
|
cases, GDB normally works with the virtual format only (the format
|
|
that makes sense for your program), but the <CODE>info registers</CODE> command
|
|
prints the data in both formats.
|
|
|
|
</P>
|
|
<P>
|
|
Normally, register values are relative to the selected stack frame
|
|
(see section <A HREF="gdb.html#SEC43">Selecting a frame</A>). This means that you get the
|
|
value that the register would contain if all stack frames farther in
|
|
were exited and their saved registers restored. In order to see the
|
|
true contents of hardware registers, you must select the innermost
|
|
frame (with <SAMP>`frame 0'</SAMP>).
|
|
|
|
</P>
|
|
<P>
|
|
However, GDB must deduce where registers are saved, from the machine
|
|
code generated by your compiler. If some registers are not saved, or if
|
|
GDB is unable to locate the saved registers, the selected stack
|
|
frame makes no difference.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set rstack_high_address <VAR>address</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX322"></A>
|
|
<A NAME="IDX323"></A>
|
|
<A NAME="IDX324"></A>
|
|
|
|
On AMD 29000 family processors, registers are saved in a separate
|
|
"register stack". There is no way for GDB to determine the extent
|
|
of this stack. Normally, GDB just assumes that the stack is "large
|
|
enough". This may result in GDB referencing memory locations that
|
|
do not exist. If necessary, you can get around this problem by
|
|
specifying the ending address of the register stack with the <CODE>set
|
|
rstack_high_address</CODE> command. The argument should be an address, which
|
|
you probably want to precede with <SAMP>`0x'</SAMP> to specify in
|
|
hexadecimal.
|
|
|
|
<A NAME="IDX325"></A>
|
|
<DT><CODE>show rstack_high_address</CODE>
|
|
<DD>
|
|
Display the current limit of the register stack, on AMD 29000 family
|
|
processors.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC62" HREF="gdb_toc.html#TOC62">Floating point hardware</A></H2>
|
|
<P>
|
|
<A NAME="IDX326"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Depending on the configuration, GDB may be able to give
|
|
you more information about the status of the floating point hardware.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info float</CODE>
|
|
<DD>
|
|
<A NAME="IDX327"></A>
|
|
|
|
Display hardware-dependent information about the floating
|
|
point unit. The exact contents and layout vary depending on the
|
|
floating point chip. Currently, <SAMP>`info float'</SAMP> is supported on
|
|
the ARM and x86 machines.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC63" HREF="gdb_toc.html#TOC63">Using GDB with Different Languages</A></H1>
|
|
<P>
|
|
<A NAME="IDX328"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Although programming languages generally have common aspects, they are
|
|
rarely expressed in the same manner. For instance, in ANSI C,
|
|
dereferencing a pointer <CODE>p</CODE> is accomplished by <CODE>*p</CODE>, but in
|
|
Modula-2, it is accomplished by <CODE>p^</CODE>. Values can also be
|
|
represented (and displayed) differently. Hex numbers in C appear as
|
|
<SAMP>`0x1ae'</SAMP>, while in Modula-2 they appear as <SAMP>`1AEH'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX329"></A>
|
|
Language-specific information is built into GDB for some languages,
|
|
allowing you to express operations like the above in your program's
|
|
native language, and allowing GDB to output values in a manner
|
|
consistent with the syntax of your program's native language. The
|
|
language you use to build expressions is called the <STRONG>working
|
|
language</STRONG>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC64" HREF="gdb_toc.html#TOC64">Switching between source languages</A></H2>
|
|
|
|
<P>
|
|
There are two ways to control the working language--either have GDB
|
|
set it automatically, or select it manually yourself. You can use the
|
|
<CODE>set language</CODE> command for either purpose. On startup, GDB
|
|
defaults to setting the language automatically. The working language is
|
|
used to determine how expressions you type are interpreted, how values
|
|
are printed, etc.
|
|
|
|
</P>
|
|
<P>
|
|
In addition to the working language, every source file that
|
|
GDB knows about has its own working language. For some object
|
|
file formats, the compiler might indicate which language a particular
|
|
source file is in. However, most of the time GDB infers the
|
|
language from the name of the file. The language of a source file
|
|
controls whether C++ names are demangled--this way <CODE>backtrace</CODE> can
|
|
show each frame appropriately for its own language. There is no way to
|
|
set the language of a source file from within GDB.
|
|
|
|
</P>
|
|
<P>
|
|
This is most commonly a problem when you use a program, such
|
|
as <CODE>cfront</CODE> or <CODE>f2c</CODE>, that generates C but is written in
|
|
another language. In that case, make the
|
|
program use <CODE>#line</CODE> directives in its C output; that way
|
|
GDB will know the correct language of the source code of the original
|
|
program, and will display that source code, not the generated C code.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC65" HREF="gdb_toc.html#TOC65">List of filename extensions and languages</A></H3>
|
|
|
|
<P>
|
|
If a source file name ends in one of the following extensions, then
|
|
GDB infers that its language is the one indicated.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><TT>`.mod'</TT>
|
|
<DD>
|
|
Modula-2 source file
|
|
|
|
<DT><TT>`.c'</TT>
|
|
<DD>
|
|
C source file
|
|
|
|
<DT><TT>`.C'</TT>
|
|
<DD>
|
|
<DT><TT>`.cc'</TT>
|
|
<DD>
|
|
<DT><TT>`.cxx'</TT>
|
|
<DD>
|
|
<DT><TT>`.cpp'</TT>
|
|
<DD>
|
|
<DT><TT>`.cp'</TT>
|
|
<DD>
|
|
<DT><TT>`.c++'</TT>
|
|
<DD>
|
|
C++ source file
|
|
|
|
<DT><TT>`.ch'</TT>
|
|
<DD>
|
|
<DT><TT>`.c186'</TT>
|
|
<DD>
|
|
<DT><TT>`.c286'</TT>
|
|
<DD>
|
|
CHILL source file.
|
|
|
|
<DT><TT>`.s'</TT>
|
|
<DD>
|
|
<DT><TT>`.S'</TT>
|
|
<DD>
|
|
Assembler source file. This actually behaves almost like C, but
|
|
GDB does not skip over function prologues when stepping.
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC66" HREF="gdb_toc.html#TOC66">Setting the working language</A></H3>
|
|
|
|
<P>
|
|
If you allow GDB to set the language automatically,
|
|
expressions are interpreted the same way in your debugging session and
|
|
your program.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX330"></A>
|
|
If you wish, you may set the language manually. To do this, issue the
|
|
command <SAMP>`set language <VAR>lang</VAR>'</SAMP>, where <VAR>lang</VAR> is the name of
|
|
a language, such as
|
|
<CODE>c</CODE> or <CODE>modula-2</CODE>.
|
|
For a list of the supported languages, type <SAMP>`set language'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
Setting the language manually prevents GDB from updating the working
|
|
language automatically. This can lead to confusion if you try
|
|
to debug a program when the working language is not the same as the
|
|
source language, when an expression is acceptable to both
|
|
languages--but means different things. For instance, if the current
|
|
source file were written in C, and GDB was parsing Modula-2, a
|
|
command such as:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
print a = b + c
|
|
</PRE>
|
|
|
|
<P>
|
|
might not have the effect you intended. In C, this means to add
|
|
<CODE>b</CODE> and <CODE>c</CODE> and place the result in <CODE>a</CODE>. The result
|
|
printed would be the value of <CODE>a</CODE>. In Modula-2, this means to compare
|
|
<CODE>a</CODE> to the result of <CODE>b+c</CODE>, yielding a <CODE>BOOLEAN</CODE> value.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC67" HREF="gdb_toc.html#TOC67">Having GDB infer the source language</A></H3>
|
|
|
|
<P>
|
|
To have GDB set the working language automatically, use
|
|
<SAMP>`set language local'</SAMP> or <SAMP>`set language auto'</SAMP>. GDB
|
|
then infers the working language. That is, when your program stops in a
|
|
frame (usually by encountering a breakpoint), GDB sets the
|
|
working language to the language recorded for the function in that
|
|
frame. If the language for a frame is unknown (that is, if the function
|
|
or block corresponding to the frame was defined in a source file that
|
|
does not have a recognized extension), the current working language is
|
|
not changed, and GDB issues a warning.
|
|
|
|
</P>
|
|
<P>
|
|
This may not seem necessary for most programs, which are written
|
|
entirely in one source language. However, program modules and libraries
|
|
written in one source language can be used by a main program written in
|
|
a different source language. Using <SAMP>`set language auto'</SAMP> in this
|
|
case frees you from having to set the working language manually.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC68" HREF="gdb_toc.html#TOC68">Displaying the language</A></H2>
|
|
|
|
<P>
|
|
The following commands help you find out which language is the
|
|
working language, and also what language source files were written in.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX331"></A>
|
|
<A NAME="IDX332"></A>
|
|
<A NAME="IDX333"></A>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>show language</CODE>
|
|
<DD>
|
|
Display the current working language. This is the
|
|
language you can use with commands such as <CODE>print</CODE> to
|
|
build and compute expressions that may involve variables in your program.
|
|
|
|
<DT><CODE>info frame</CODE>
|
|
<DD>
|
|
Display the source language for this frame. This language becomes the
|
|
working language if you use an identifier from this frame.
|
|
See section <A HREF="gdb.html#SEC44">Information about a frame</A>, to identify the other
|
|
information listed here.
|
|
|
|
<DT><CODE>info source</CODE>
|
|
<DD>
|
|
Display the source language of this source file.
|
|
See section <A HREF="gdb.html#SEC90">Examining the Symbol Table</A>, to identify the other
|
|
information listed here.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC69" HREF="gdb_toc.html#TOC69">Type and range checking</A></H2>
|
|
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> In this release, the GDB commands for type and range
|
|
checking are included, but they do not yet have any effect. This
|
|
section documents the intended facilities.
|
|
</BLOCKQUOTE>
|
|
|
|
<P>
|
|
Some languages are designed to guard you against making seemingly common
|
|
errors through a series of compile- and run-time checks. These include
|
|
checking the type of arguments to functions and operators, and making
|
|
sure mathematical overflows are caught at run time. Checks such as
|
|
these help to ensure a program's correctness once it has been compiled
|
|
by eliminating type mismatches, and providing active checks for range
|
|
errors when your program is running.
|
|
|
|
</P>
|
|
<P>
|
|
GDB can check for conditions like the above if you wish.
|
|
Although GDB does not check the statements in your program, it
|
|
can check expressions entered directly into GDB for evaluation via
|
|
the <CODE>print</CODE> command, for example. As with the working language,
|
|
GDB can also decide whether or not to check automatically based on
|
|
your program's source language. See section <A HREF="gdb.html#SEC72">Supported languages</A>,
|
|
for the default settings of supported languages.
|
|
|
|
</P>
|
|
|
|
<P>
|
|
<A NAME="IDX334"></A>
|
|
<A NAME="IDX335"></A>
|
|
|
|
|
|
<H3><A NAME="SEC70" HREF="gdb_toc.html#TOC70">An overview of type checking</A></H3>
|
|
|
|
<P>
|
|
Some languages, such as Modula-2, are strongly typed, meaning that the
|
|
arguments to operators and functions have to be of the correct type,
|
|
otherwise an error occurs. These checks prevent type mismatch
|
|
errors from ever causing any run-time problems. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
1 + 2 => 3
|
|
but
|
|
error--> 1 + 2.3
|
|
</PRE>
|
|
|
|
<P>
|
|
The second example fails because the <CODE>CARDINAL</CODE> 1 is not
|
|
type-compatible with the <CODE>REAL</CODE> 2.3.
|
|
|
|
</P>
|
|
<P>
|
|
For the expressions you use in GDB commands, you can tell the
|
|
GDB type checker to skip checking;
|
|
to treat any mismatches as errors and abandon the expression;
|
|
or to only issue warnings when type mismatches occur,
|
|
but evaluate the expression anyway. When you choose the last of
|
|
these, GDB evaluates expressions like the second example above, but
|
|
also issues a warning.
|
|
|
|
</P>
|
|
<P>
|
|
Even if you turn type checking off, there may be other reasons
|
|
related to type that prevent GDB from evaluating an expression.
|
|
For instance, GDB does not know how to add an <CODE>int</CODE> and
|
|
a <CODE>struct foo</CODE>. These particular type errors have nothing to do
|
|
with the language in use, and usually arise from expressions, such as
|
|
the one described above, which make little sense to evaluate anyway.
|
|
|
|
</P>
|
|
<P>
|
|
Each language defines to what degree it is strict about type. For
|
|
instance, both Modula-2 and C require the arguments to arithmetical
|
|
operators to be numbers. In C, enumerated types and pointers can be
|
|
represented as numbers, so that they are valid arguments to mathematical
|
|
operators. See section <A HREF="gdb.html#SEC72">Supported languages</A>, for further
|
|
details on specific languages.
|
|
|
|
</P>
|
|
<P>
|
|
GDB provides some additional commands for controlling the type checker:
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX336"></A>
|
|
<A NAME="IDX337"></A>
|
|
<A NAME="IDX338"></A>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set check type auto</CODE>
|
|
<DD>
|
|
Set type checking on or off based on the current working language.
|
|
See section <A HREF="gdb.html#SEC72">Supported languages</A>, for the default settings for
|
|
each language.
|
|
|
|
<DT><CODE>set check type on</CODE>
|
|
<DD>
|
|
<DT><CODE>set check type off</CODE>
|
|
<DD>
|
|
Set type checking on or off, overriding the default setting for the
|
|
current working language. Issue a warning if the setting does not
|
|
match the language default. If any type mismatches occur in
|
|
evaluating an expression while typechecking is on, GDB prints a
|
|
message and aborts evaluation of the expression.
|
|
|
|
<DT><CODE>set check type warn</CODE>
|
|
<DD>
|
|
Cause the type checker to issue warnings, but to always attempt to
|
|
evaluate the expression. Evaluating the expression may still
|
|
be impossible for other reasons. For example, GDB cannot add
|
|
numbers and structures.
|
|
|
|
<DT><CODE>show type</CODE>
|
|
<DD>
|
|
Show the current setting of the type checker, and whether or not GDB
|
|
is setting it automatically.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX339"></A>
|
|
<A NAME="IDX340"></A>
|
|
|
|
|
|
<H3><A NAME="SEC71" HREF="gdb_toc.html#TOC71">An overview of range checking</A></H3>
|
|
|
|
<P>
|
|
In some languages (such as Modula-2), it is an error to exceed the
|
|
bounds of a type; this is enforced with run-time checks. Such range
|
|
checking is meant to ensure program correctness by making sure
|
|
computations do not overflow, or indices on an array element access do
|
|
not exceed the bounds of the array.
|
|
|
|
</P>
|
|
<P>
|
|
For expressions you use in GDB commands, you can tell
|
|
GDB to treat range errors in one of three ways: ignore them,
|
|
always treat them as errors and abandon the expression, or issue
|
|
warnings but evaluate the expression anyway.
|
|
|
|
</P>
|
|
<P>
|
|
A range error can result from numerical overflow, from exceeding an
|
|
array index bound, or when you type a constant that is not a member
|
|
of any type. Some languages, however, do not treat overflows as an
|
|
error. In many implementations of C, mathematical overflow causes the
|
|
result to "wrap around" to lower values--for example, if <VAR>m</VAR> is
|
|
the largest integer value, and <VAR>s</VAR> is the smallest, then
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>m</VAR> + 1 => <VAR>s</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
This, too, is specific to individual languages, and in some cases
|
|
specific to individual compilers or machines. See section <A HREF="gdb.html#SEC72">Supported languages</A>, for further details on specific languages.
|
|
|
|
</P>
|
|
<P>
|
|
GDB provides some additional commands for controlling the range checker:
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX341"></A>
|
|
<A NAME="IDX342"></A>
|
|
<A NAME="IDX343"></A>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set check range auto</CODE>
|
|
<DD>
|
|
Set range checking on or off based on the current working language.
|
|
See section <A HREF="gdb.html#SEC72">Supported languages</A>, for the default settings for
|
|
each language.
|
|
|
|
<DT><CODE>set check range on</CODE>
|
|
<DD>
|
|
<DT><CODE>set check range off</CODE>
|
|
<DD>
|
|
Set range checking on or off, overriding the default setting for the
|
|
current working language. A warning is issued if the setting does not
|
|
match the language default. If a range error occurs, then a message
|
|
is printed and evaluation of the expression is aborted.
|
|
|
|
<DT><CODE>set check range warn</CODE>
|
|
<DD>
|
|
Output messages when the GDB range checker detects a range error,
|
|
but attempt to evaluate the expression anyway. Evaluating the
|
|
expression may still be impossible for other reasons, such as accessing
|
|
memory that the process does not own (a typical example from many Unix
|
|
systems).
|
|
|
|
<DT><CODE>show range</CODE>
|
|
<DD>
|
|
Show the current setting of the range checker, and whether or not it is
|
|
being set automatically by GDB.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC72" HREF="gdb_toc.html#TOC72">Supported languages</A></H2>
|
|
|
|
<P>
|
|
GDB 4 supports C, C++, and Modula-2.
|
|
Some GDB features may be used in expressions regardless of the
|
|
language you use: the GDB <CODE>@</CODE> and <CODE>::</CODE> operators,
|
|
and the <SAMP>`{type}addr'</SAMP> construct (see section <A HREF="gdb.html#SEC52">Expressions</A>) can be used with the constructs of any supported
|
|
language.
|
|
|
|
</P>
|
|
<P>
|
|
The following sections detail to what degree each source language is
|
|
supported by GDB. These sections are not meant to be language
|
|
tutorials or references, but serve only as a reference guide to what the
|
|
GDB expression parser accepts, and what input and output
|
|
formats should look like for different languages. There are many good
|
|
books written on each of these languages; please look to these for a
|
|
language reference or tutorial.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC73" HREF="gdb_toc.html#TOC73">C and C++</A></H3>
|
|
<P>
|
|
<A NAME="IDX344"></A>
|
|
<A NAME="IDX345"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Since C and C++ are so closely related, many features of GDB apply
|
|
to both languages. Whenever this is the case, we discuss those languages
|
|
together.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX346"></A>
|
|
<A NAME="IDX347"></A>
|
|
<A NAME="IDX348"></A>
|
|
The C++ debugging facilities are jointly implemented by the GNU C++
|
|
compiler and GDB. Therefore, to debug your C++ code
|
|
effectively, you must compile your C++ programs with the GNU C++
|
|
compiler, <CODE>g++</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
For best results when debugging C++ programs, use the stabs debugging
|
|
format. You can select that format explicitly with the <CODE>g++</CODE>
|
|
command-line options <SAMP>`-gstabs'</SAMP> or <SAMP>`-gstabs+'</SAMP>. See
|
|
section `Options for Debugging Your Program or GNU CC' in <CITE>Using GNU CC</CITE>, for more information.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX349"></A>
|
|
|
|
|
|
<H4><A NAME="SEC74" HREF="gdb_toc.html#TOC74">C and C++ operators</A></H4>
|
|
|
|
<P>
|
|
Operators must be defined on values of specific types. For instance,
|
|
<CODE>+</CODE> is defined on numbers, but not on structures. Operators are
|
|
often defined on groups of types.
|
|
|
|
</P>
|
|
<P>
|
|
For the purposes of C and C++, the following definitions hold:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
<EM>Integral types</EM> include <CODE>int</CODE> with any of its storage-class
|
|
specifiers; <CODE>char</CODE>; and <CODE>enum</CODE>.
|
|
|
|
<LI>
|
|
|
|
<EM>Floating-point types</EM> include <CODE>float</CODE> and <CODE>double</CODE>.
|
|
|
|
<LI>
|
|
|
|
<EM>Pointer types</EM> include all types defined as <CODE>(<VAR>type</VAR>
|
|
*)</CODE>.
|
|
|
|
<LI>
|
|
|
|
<EM>Scalar types</EM> include all of the above.
|
|
</UL>
|
|
|
|
<P>
|
|
The following operators are supported. They are listed here
|
|
in order of increasing precedence:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>,</CODE>
|
|
<DD>
|
|
The comma or sequencing operator. Expressions in a comma-separated list
|
|
are evaluated from left to right, with the result of the entire
|
|
expression being the last expression evaluated.
|
|
|
|
<DT><CODE>=</CODE>
|
|
<DD>
|
|
Assignment. The value of an assignment expression is the value
|
|
assigned. Defined on scalar types.
|
|
|
|
<DT><CODE><VAR>op</VAR>=</CODE>
|
|
<DD>
|
|
Used in an expression of the form <CODE><VAR>a</VAR> <VAR>op</VAR>= <VAR>b</VAR></CODE>,
|
|
and translated to <CODE><VAR>a</VAR> = <VAR>a op b</VAR></CODE>.
|
|
<CODE><VAR>op</VAR>=</CODE> and <CODE>=</CODE> have the same precendence.
|
|
<VAR>op</VAR> is any one of the operators <CODE>|</CODE>, <CODE>^</CODE>, <CODE>&</CODE>,
|
|
<CODE><<</CODE>, <CODE>>></CODE>, <CODE>+</CODE>, <CODE>-</CODE>, <CODE>*</CODE>, <CODE>/</CODE>, <CODE>%</CODE>.
|
|
|
|
<DT><CODE>?:</CODE>
|
|
<DD>
|
|
The ternary operator. <CODE><VAR>a</VAR> ? <VAR>b</VAR> : <VAR>c</VAR></CODE> can be thought
|
|
of as: if <VAR>a</VAR> then <VAR>b</VAR> else <VAR>c</VAR>. <VAR>a</VAR> should be of an
|
|
integral type.
|
|
|
|
<DT><CODE>||</CODE>
|
|
<DD>
|
|
Logical OR. Defined on integral types.
|
|
|
|
<DT><CODE>&&</CODE>
|
|
<DD>
|
|
Logical AND. Defined on integral types.
|
|
|
|
<DT><CODE>|</CODE>
|
|
<DD>
|
|
Bitwise OR. Defined on integral types.
|
|
|
|
<DT><CODE>^</CODE>
|
|
<DD>
|
|
Bitwise exclusive-OR. Defined on integral types.
|
|
|
|
<DT><CODE>&</CODE>
|
|
<DD>
|
|
Bitwise AND. Defined on integral types.
|
|
|
|
<DT><CODE>==, !=</CODE>
|
|
<DD>
|
|
Equality and inequality. Defined on scalar types. The value of these
|
|
expressions is 0 for false and non-zero for true.
|
|
|
|
<DT><CODE><, >, <=, >=</CODE>
|
|
<DD>
|
|
Less than, greater than, less than or equal, greater than or equal.
|
|
Defined on scalar types. The value of these expressions is 0 for false
|
|
and non-zero for true.
|
|
|
|
<DT><CODE><<, >></CODE>
|
|
<DD>
|
|
left shift, and right shift. Defined on integral types.
|
|
|
|
<DT><CODE>@</CODE>
|
|
<DD>
|
|
The GDB "artificial array" operator (see section <A HREF="gdb.html#SEC52">Expressions</A>).
|
|
|
|
<DT><CODE>+, -</CODE>
|
|
<DD>
|
|
Addition and subtraction. Defined on integral types, floating-point types and
|
|
pointer types.
|
|
|
|
<DT><CODE>*, /, %</CODE>
|
|
<DD>
|
|
Multiplication, division, and modulus. Multiplication and division are
|
|
defined on integral and floating-point types. Modulus is defined on
|
|
integral types.
|
|
|
|
<DT><CODE>++, --</CODE>
|
|
<DD>
|
|
Increment and decrement. When appearing before a variable, the
|
|
operation is performed before the variable is used in an expression;
|
|
when appearing after it, the variable's value is used before the
|
|
operation takes place.
|
|
|
|
<DT><CODE>*</CODE>
|
|
<DD>
|
|
Pointer dereferencing. Defined on pointer types. Same precedence as
|
|
<CODE>++</CODE>.
|
|
|
|
<DT><CODE>&</CODE>
|
|
<DD>
|
|
Address operator. Defined on variables. Same precedence as <CODE>++</CODE>.
|
|
|
|
For debugging C++, GDB implements a use of <SAMP>`&'</SAMP> beyond what is
|
|
allowed in the C++ language itself: you can use <SAMP>`&(&<VAR>ref</VAR>)'</SAMP>
|
|
(or, if you prefer, simply <SAMP>`&&<VAR>ref</VAR>'</SAMP>) to examine the address
|
|
where a C++ reference variable (declared with <SAMP>`&<VAR>ref</VAR>'</SAMP>) is
|
|
stored.
|
|
|
|
<DT><CODE>-</CODE>
|
|
<DD>
|
|
Negative. Defined on integral and floating-point types. Same
|
|
precedence as <CODE>++</CODE>.
|
|
|
|
<DT><CODE>!</CODE>
|
|
<DD>
|
|
Logical negation. Defined on integral types. Same precedence as
|
|
<CODE>++</CODE>.
|
|
|
|
<DT><CODE>~</CODE>
|
|
<DD>
|
|
Bitwise complement operator. Defined on integral types. Same precedence as
|
|
<CODE>++</CODE>.
|
|
|
|
<DT><CODE>., -></CODE>
|
|
<DD>
|
|
Structure member, and pointer-to-structure member. For convenience,
|
|
GDB regards the two as equivalent, choosing whether to dereference a
|
|
pointer based on the stored type information.
|
|
Defined on <CODE>struct</CODE> and <CODE>union</CODE> data.
|
|
|
|
<DT><CODE>[]</CODE>
|
|
<DD>
|
|
Array indexing. <CODE><VAR>a</VAR>[<VAR>i</VAR>]</CODE> is defined as
|
|
<CODE>*(<VAR>a</VAR>+<VAR>i</VAR>)</CODE>. Same precedence as <CODE>-></CODE>.
|
|
|
|
<DT><CODE>()</CODE>
|
|
<DD>
|
|
Function parameter list. Same precedence as <CODE>-></CODE>.
|
|
|
|
<DT><CODE>::</CODE>
|
|
<DD>
|
|
C++ scope resolution operator. Defined on
|
|
<CODE>struct</CODE>, <CODE>union</CODE>, and <CODE>class</CODE> types.
|
|
|
|
<DT><CODE>::</CODE>
|
|
<DD>
|
|
Doubled colons
|
|
also
|
|
represent the GDB scope operator (see section <A HREF="gdb.html#SEC52">Expressions</A>).
|
|
Same precedence as <CODE>::</CODE>, above.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX350"></A>
|
|
|
|
|
|
<H4><A NAME="SEC75" HREF="gdb_toc.html#TOC75">C and C++ constants</A></H4>
|
|
|
|
<P>
|
|
GDB allows you to express the constants of C and C++ in the
|
|
following ways:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Integer constants are a sequence of digits. Octal constants are
|
|
specified by a leading <SAMP>`0'</SAMP> (i.e. zero), and hexadecimal constants by
|
|
a leading <SAMP>`0x'</SAMP> or <SAMP>`0X'</SAMP>. Constants may also end with a letter
|
|
<SAMP>`l'</SAMP>, specifying that the constant should be treated as a
|
|
<CODE>long</CODE> value.
|
|
|
|
<LI>
|
|
|
|
Floating point constants are a sequence of digits, followed by a decimal
|
|
point, followed by a sequence of digits, and optionally followed by an
|
|
exponent. An exponent is of the form:
|
|
<SAMP>`e[[+]|-]<VAR>nnn</VAR>'</SAMP>, where <VAR>nnn</VAR> is another
|
|
sequence of digits. The <SAMP>`+'</SAMP> is optional for positive exponents.
|
|
|
|
<LI>
|
|
|
|
Enumerated constants consist of enumerated identifiers, or their
|
|
integral equivalents.
|
|
|
|
<LI>
|
|
|
|
Character constants are a single character surrounded by single quotes
|
|
(<CODE>'</CODE>), or a number--the ordinal value of the corresponding character
|
|
(usually its ASCII value). Within quotes, the single character may
|
|
be represented by a letter or by <STRONG>escape sequences</STRONG>, which are of
|
|
the form <SAMP>`\<VAR>nnn</VAR>'</SAMP>, where <VAR>nnn</VAR> is the octal representation
|
|
of the character's ordinal value; or of the form <SAMP>`\<VAR>x</VAR>'</SAMP>, where
|
|
<SAMP>`<VAR>x</VAR>'</SAMP> is a predefined special character--for example,
|
|
<SAMP>`\n'</SAMP> for newline.
|
|
|
|
<LI>
|
|
|
|
String constants are a sequence of character constants surrounded
|
|
by double quotes (<CODE>"</CODE>).
|
|
|
|
<LI>
|
|
|
|
Pointer constants are an integral value. You can also write pointers
|
|
to constants using the C operator <SAMP>`&'</SAMP>.
|
|
|
|
<LI>
|
|
|
|
Array constants are comma-separated lists surrounded by braces <SAMP>`{'</SAMP>
|
|
and <SAMP>`}'</SAMP>; for example, <SAMP>`{1,2,3}'</SAMP> is a three-element array of
|
|
integers, <SAMP>`{{1,2}, {3,4}, {5,6}}'</SAMP> is a three-by-two array,
|
|
and <SAMP>`{&"hi", &"there", &"fred"}'</SAMP> is a three-element array of pointers.
|
|
</UL>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC76" HREF="gdb_toc.html#TOC76">C++ expressions</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX351"></A>
|
|
GDB expression handling has a number of extensions to
|
|
interpret a significant subset of C++ expressions.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX352"></A>
|
|
<A NAME="IDX353"></A>
|
|
<A NAME="IDX354"></A>
|
|
<A NAME="IDX355"></A>
|
|
<A NAME="IDX356"></A>
|
|
<A NAME="IDX357"></A>
|
|
<A NAME="IDX358"></A>
|
|
<A NAME="IDX359"></A>
|
|
<A NAME="IDX360"></A>
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> GDB can only debug C++ code if you compile with
|
|
the GNU C++ compiler. Moreover, C++ debugging depends on the use of
|
|
additional debugging information in the symbol table, and thus requires
|
|
special support. GDB has this support <EM>only</EM> with the
|
|
stabs debug format. In particular, if your compiler generates a.out,
|
|
MIPS ECOFF, RS/6000 XCOFF, or ELF with stabs extensions
|
|
to the symbol table, these facilities are all available. (With GNU CC,
|
|
you can use the <SAMP>`-gstabs'</SAMP> option to request stabs debugging
|
|
extensions explicitly.) Where the object code format is standard
|
|
COFF or DWARF in ELF, on the other hand, most of the C++
|
|
support in GDB does <EM>not</EM> work.
|
|
</BLOCKQUOTE>
|
|
|
|
|
|
<OL>
|
|
|
|
<LI>
|
|
|
|
<A NAME="IDX361"></A>
|
|
|
|
Member function calls are allowed; you can use expressions like
|
|
|
|
|
|
<PRE>
|
|
count = aml->GetOriginal(x, y)
|
|
</PRE>
|
|
|
|
<A NAME="IDX362"></A>
|
|
<A NAME="IDX363"></A>
|
|
<LI>
|
|
|
|
While a member function is active (in the selected stack frame), your
|
|
expressions have the same namespace available as the member function;
|
|
that is, GDB allows implicit references to the class instance
|
|
pointer <CODE>this</CODE> following the same rules as C++.
|
|
|
|
<A NAME="IDX364"></A>
|
|
<A NAME="IDX365"></A>
|
|
<LI>
|
|
|
|
You can call overloaded functions; GDB resolves the function
|
|
call to the right definition, with one restriction--you must use
|
|
arguments of the type required by the function that you want to call.
|
|
GDB does not perform conversions requiring constructors or
|
|
user-defined type operators.
|
|
|
|
<A NAME="IDX366"></A>
|
|
<LI>
|
|
|
|
GDB understands variables declared as C++ references; you can use
|
|
them in expressions just as you do in C++ source--they are automatically
|
|
dereferenced.
|
|
|
|
In the parameter list shown when GDB displays a frame, the values of
|
|
reference variables are not displayed (unlike other variables); this
|
|
avoids clutter, since references are often used for large structures.
|
|
The <EM>address</EM> of a reference variable is always shown, unless
|
|
you have specified <SAMP>`set print address off'</SAMP>.
|
|
|
|
<LI>
|
|
|
|
GDB supports the C++ name resolution operator <CODE>::</CODE>---your
|
|
expressions can use it just as expressions in your program do. Since
|
|
one scope may be defined in another, you can use <CODE>::</CODE> repeatedly if
|
|
necessary, for example in an expression like
|
|
<SAMP>`<VAR>scope1</VAR>::<VAR>scope2</VAR>::<VAR>name</VAR>'</SAMP>. GDB also allows
|
|
resolving name scope by reference to source files, in both C and C++
|
|
debugging (see section <A HREF="gdb.html#SEC53">Program variables</A>).
|
|
</OL>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC77" HREF="gdb_toc.html#TOC77">C and C++ defaults</A></H4>
|
|
<P>
|
|
<A NAME="IDX367"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If you allow GDB to set type and range checking automatically, they
|
|
both default to <CODE>off</CODE> whenever the working language changes to
|
|
C or C++. This happens regardless of whether you or GDB
|
|
selects the working language.
|
|
|
|
</P>
|
|
<P>
|
|
If you allow GDB to set the language automatically, it recognizes
|
|
source files whose names end with <TT>`.c'</TT>, <TT>`.C'</TT>, or <TT>`.cc'</TT>, and
|
|
when GDB enters code compiled from one of these files,
|
|
it sets the working language to C or C++.
|
|
See section <A HREF="gdb.html#SEC67">Having GDB infer the source language</A>, for
|
|
further details.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC78" HREF="gdb_toc.html#TOC78">C and C++ type and range checks</A></H4>
|
|
<P>
|
|
<A NAME="IDX368"></A>
|
|
|
|
</P>
|
|
<P>
|
|
By default, when GDB parses C or C++ expressions, type checking
|
|
is not used. However, if you turn type checking on, GDB
|
|
considers two variables type equivalent if:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
The two variables are structured and have the same structure, union, or
|
|
enumerated tag.
|
|
|
|
<LI>
|
|
|
|
The two variables have the same type name, or types that have been
|
|
declared equivalent through <CODE>typedef</CODE>.
|
|
|
|
</UL>
|
|
|
|
<P>
|
|
Range checking, if turned on, is done on mathematical operations. Array
|
|
indices are not checked, since they are often used to index a pointer
|
|
that is not itself an array.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC79" HREF="gdb_toc.html#TOC79">GDB and C</A></H4>
|
|
|
|
<P>
|
|
The <CODE>set print union</CODE> and <CODE>show print union</CODE> commands apply to
|
|
the <CODE>union</CODE> type. When set to <SAMP>`on'</SAMP>, any <CODE>union</CODE> that is
|
|
inside a <CODE>struct</CODE>
|
|
or <CODE>class</CODE>
|
|
is also printed.
|
|
Otherwise, it appears as <SAMP>`{...}'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>@</CODE> operator aids in the debugging of dynamic arrays, formed
|
|
with pointers and a memory allocation function. See section <A HREF="gdb.html#SEC52">Expressions</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC80" HREF="gdb_toc.html#TOC80">GDB features for C++</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX369"></A>
|
|
Some GDB commands are particularly useful with C++, and some are
|
|
designed specifically for use with C++. Here is a summary:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>breakpoint menus</CODE>
|
|
<DD>
|
|
<A NAME="IDX370"></A>
|
|
|
|
When you want a breakpoint in a function whose name is overloaded,
|
|
GDB breakpoint menus help you specify which function definition
|
|
you want. See section <A HREF="gdb.html#SEC36">Breakpoint menus</A>.
|
|
|
|
<A NAME="IDX371"></A>
|
|
<DT><CODE>rbreak <VAR>regex</VAR></CODE>
|
|
<DD>
|
|
Setting breakpoints using regular expressions is helpful for setting
|
|
breakpoints on overloaded functions that are not members of any special
|
|
classes.
|
|
See section <A HREF="gdb.html#SEC29">Setting breakpoints</A>.
|
|
|
|
<A NAME="IDX372"></A>
|
|
<DT><CODE>catch <VAR>exceptions</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>info catch</CODE>
|
|
<DD>
|
|
Debug C++ exception handling using these commands. See section <A HREF="gdb.html#SEC31">Breakpoints and exceptions</A>.
|
|
|
|
<A NAME="IDX373"></A>
|
|
<DT><CODE>ptype <VAR>typename</VAR></CODE>
|
|
<DD>
|
|
Print inheritance relationships as well as other information for type
|
|
<VAR>typename</VAR>.
|
|
See section <A HREF="gdb.html#SEC90">Examining the Symbol Table</A>.
|
|
|
|
<A NAME="IDX374"></A>
|
|
<DT><CODE>set print demangle</CODE>
|
|
<DD>
|
|
<DT><CODE>show print demangle</CODE>
|
|
<DD>
|
|
<DT><CODE>set print asm-demangle</CODE>
|
|
<DD>
|
|
<DT><CODE>show print asm-demangle</CODE>
|
|
<DD>
|
|
Control whether C++ symbols display in their source form, both when
|
|
displaying code as C++ source and when displaying disassemblies.
|
|
See section <A HREF="gdb.html#SEC58">Print settings</A>.
|
|
|
|
<DT><CODE>set print object</CODE>
|
|
<DD>
|
|
<DT><CODE>show print object</CODE>
|
|
<DD>
|
|
Choose whether to print derived (actual) or declared types of objects.
|
|
See section <A HREF="gdb.html#SEC58">Print settings</A>.
|
|
|
|
<DT><CODE>set print vtbl</CODE>
|
|
<DD>
|
|
<DT><CODE>show print vtbl</CODE>
|
|
<DD>
|
|
Control the format for printing virtual function tables.
|
|
See section <A HREF="gdb.html#SEC58">Print settings</A>.
|
|
|
|
<DT><CODE>Overloaded symbol names</CODE>
|
|
<DD>
|
|
You can specify a particular definition of an overloaded symbol, using
|
|
the same notation that is used to declare such symbols in C++: type
|
|
<CODE><VAR>symbol</VAR>(<VAR>types</VAR>)</CODE> rather than just <VAR>symbol</VAR>. You can
|
|
also use the GDB command-line word completion facilities to list the
|
|
available choices, or to finish the type list for you.
|
|
See section <A HREF="gdb.html#SEC13">Command completion</A>, for details on how to do this.
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC81" HREF="gdb_toc.html#TOC81">Modula-2</A></H3>
|
|
<P>
|
|
<A NAME="IDX375"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The extensions made to GDB to support Modula-2 only support
|
|
output from the GNU Modula-2 compiler (which is currently being
|
|
developed). Other Modula-2 compilers are not currently supported, and
|
|
attempting to debug executables produced by them is most likely
|
|
to give an error as GDB reads in the executable's symbol
|
|
table.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX376"></A>
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC82" HREF="gdb_toc.html#TOC82">Operators</A></H4>
|
|
<P>
|
|
<A NAME="IDX377"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Operators must be defined on values of specific types. For instance,
|
|
<CODE>+</CODE> is defined on numbers, but not on structures. Operators are
|
|
often defined on groups of types. For the purposes of Modula-2, the
|
|
following definitions hold:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
|
|
<LI>
|
|
|
|
<EM>Integral types</EM> consist of <CODE>INTEGER</CODE>, <CODE>CARDINAL</CODE>, and
|
|
their subranges.
|
|
|
|
<LI>
|
|
|
|
<EM>Character types</EM> consist of <CODE>CHAR</CODE> and its subranges.
|
|
|
|
<LI>
|
|
|
|
<EM>Floating-point types</EM> consist of <CODE>REAL</CODE>.
|
|
|
|
<LI>
|
|
|
|
<EM>Pointer types</EM> consist of anything declared as <CODE>POINTER TO
|
|
<VAR>type</VAR></CODE>.
|
|
|
|
<LI>
|
|
|
|
<EM>Scalar types</EM> consist of all of the above.
|
|
|
|
<LI>
|
|
|
|
<EM>Set types</EM> consist of <CODE>SET</CODE> and <CODE>BITSET</CODE> types.
|
|
|
|
<LI>
|
|
|
|
<EM>Boolean types</EM> consist of <CODE>BOOLEAN</CODE>.
|
|
</UL>
|
|
|
|
<P>
|
|
The following operators are supported, and appear in order of
|
|
increasing precedence:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>,</CODE>
|
|
<DD>
|
|
Function argument or array index separator.
|
|
|
|
<DT><CODE>:=</CODE>
|
|
<DD>
|
|
Assignment. The value of <VAR>var</VAR> <CODE>:=</CODE> <VAR>value</VAR> is
|
|
<VAR>value</VAR>.
|
|
|
|
<DT><CODE><, ></CODE>
|
|
<DD>
|
|
Less than, greater than on integral, floating-point, or enumerated
|
|
types.
|
|
|
|
<DT><CODE><=, >=</CODE>
|
|
<DD>
|
|
Less than, greater than, less than or equal to, greater than or equal to
|
|
on integral, floating-point and enumerated types, or set inclusion on
|
|
set types. Same precedence as <CODE><</CODE>.
|
|
|
|
<DT><CODE>=, <>, #</CODE>
|
|
<DD>
|
|
Equality and two ways of expressing inequality, valid on scalar types.
|
|
Same precedence as <CODE><</CODE>. In GDB scripts, only <CODE><></CODE> is
|
|
available for inequality, since <CODE>#</CODE> conflicts with the script
|
|
comment character.
|
|
|
|
<DT><CODE>IN</CODE>
|
|
<DD>
|
|
Set membership. Defined on set types and the types of their members.
|
|
Same precedence as <CODE><</CODE>.
|
|
|
|
<DT><CODE>OR</CODE>
|
|
<DD>
|
|
Boolean disjunction. Defined on boolean types.
|
|
|
|
<DT><CODE>AND, &</CODE>
|
|
<DD>
|
|
Boolean conjuction. Defined on boolean types.
|
|
|
|
<DT><CODE>@</CODE>
|
|
<DD>
|
|
The GDB "artificial array" operator (see section <A HREF="gdb.html#SEC52">Expressions</A>).
|
|
|
|
<DT><CODE>+, -</CODE>
|
|
<DD>
|
|
Addition and subtraction on integral and floating-point types, or union
|
|
and difference on set types.
|
|
|
|
<DT><CODE>*</CODE>
|
|
<DD>
|
|
Multiplication on integral and floating-point types, or set intersection
|
|
on set types.
|
|
|
|
<DT><CODE>/</CODE>
|
|
<DD>
|
|
Division on floating-point types, or symmetric set difference on set
|
|
types. Same precedence as <CODE>*</CODE>.
|
|
|
|
<DT><CODE>DIV, MOD</CODE>
|
|
<DD>
|
|
Integer division and remainder. Defined on integral types. Same
|
|
precedence as <CODE>*</CODE>.
|
|
|
|
<DT><CODE>-</CODE>
|
|
<DD>
|
|
Negative. Defined on <CODE>INTEGER</CODE> and <CODE>REAL</CODE> data.
|
|
|
|
<DT><CODE>^</CODE>
|
|
<DD>
|
|
Pointer dereferencing. Defined on pointer types.
|
|
|
|
<DT><CODE>NOT</CODE>
|
|
<DD>
|
|
Boolean negation. Defined on boolean types. Same precedence as
|
|
<CODE>^</CODE>.
|
|
|
|
<DT><CODE>.</CODE>
|
|
<DD>
|
|
<CODE>RECORD</CODE> field selector. Defined on <CODE>RECORD</CODE> data. Same
|
|
precedence as <CODE>^</CODE>.
|
|
|
|
<DT><CODE>[]</CODE>
|
|
<DD>
|
|
Array indexing. Defined on <CODE>ARRAY</CODE> data. Same precedence as <CODE>^</CODE>.
|
|
|
|
<DT><CODE>()</CODE>
|
|
<DD>
|
|
Procedure argument list. Defined on <CODE>PROCEDURE</CODE> objects. Same precedence
|
|
as <CODE>^</CODE>.
|
|
|
|
<DT><CODE>::, .</CODE>
|
|
<DD>
|
|
GDB and Modula-2 scope operators.
|
|
</DL>
|
|
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> Sets and their operations are not yet supported, so GDB
|
|
treats the use of the operator <CODE>IN</CODE>, or the use of operators
|
|
<CODE>+</CODE>, <CODE>-</CODE>, <CODE>*</CODE>, <CODE>/</CODE>, <CODE>=</CODE>, , <CODE><></CODE>, <CODE>#</CODE>,
|
|
<CODE><=</CODE>, and <CODE>>=</CODE> on sets as an error.
|
|
</BLOCKQUOTE>
|
|
|
|
<P>
|
|
<A NAME="IDX378"></A>
|
|
|
|
|
|
<H4><A NAME="SEC83" HREF="gdb_toc.html#TOC83">Built-in functions and procedures</A></H4>
|
|
|
|
<P>
|
|
Modula-2 also makes available several built-in procedures and functions.
|
|
In describing these, the following metavariables are used:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><VAR>a</VAR>
|
|
<DD>
|
|
represents an <CODE>ARRAY</CODE> variable.
|
|
|
|
<DT><VAR>c</VAR>
|
|
<DD>
|
|
represents a <CODE>CHAR</CODE> constant or variable.
|
|
|
|
<DT><VAR>i</VAR>
|
|
<DD>
|
|
represents a variable or constant of integral type.
|
|
|
|
<DT><VAR>m</VAR>
|
|
<DD>
|
|
represents an identifier that belongs to a set. Generally used in the
|
|
same function with the metavariable <VAR>s</VAR>. The type of <VAR>s</VAR> should
|
|
be <CODE>SET OF <VAR>mtype</VAR></CODE> (where <VAR>mtype</VAR> is the type of <VAR>m</VAR>).
|
|
|
|
<DT><VAR>n</VAR>
|
|
<DD>
|
|
represents a variable or constant of integral or floating-point type.
|
|
|
|
<DT><VAR>r</VAR>
|
|
<DD>
|
|
represents a variable or constant of floating-point type.
|
|
|
|
<DT><VAR>t</VAR>
|
|
<DD>
|
|
represents a type.
|
|
|
|
<DT><VAR>v</VAR>
|
|
<DD>
|
|
represents a variable.
|
|
|
|
<DT><VAR>x</VAR>
|
|
<DD>
|
|
represents a variable or constant of one of many types. See the
|
|
explanation of the function for details.
|
|
</DL>
|
|
|
|
<P>
|
|
All Modula-2 built-in procedures also return a result, described below.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>ABS(<VAR>n</VAR>)</CODE>
|
|
<DD>
|
|
Returns the absolute value of <VAR>n</VAR>.
|
|
|
|
<DT><CODE>CAP(<VAR>c</VAR>)</CODE>
|
|
<DD>
|
|
If <VAR>c</VAR> is a lower case letter, it returns its upper case
|
|
equivalent, otherwise it returns its argument
|
|
|
|
<DT><CODE>CHR(<VAR>i</VAR>)</CODE>
|
|
<DD>
|
|
Returns the character whose ordinal value is <VAR>i</VAR>.
|
|
|
|
<DT><CODE>DEC(<VAR>v</VAR>)</CODE>
|
|
<DD>
|
|
Decrements the value in the variable <VAR>v</VAR>. Returns the new value.
|
|
|
|
<DT><CODE>DEC(<VAR>v</VAR>,<VAR>i</VAR>)</CODE>
|
|
<DD>
|
|
Decrements the value in the variable <VAR>v</VAR> by <VAR>i</VAR>. Returns the
|
|
new value.
|
|
|
|
<DT><CODE>EXCL(<VAR>m</VAR>,<VAR>s</VAR>)</CODE>
|
|
<DD>
|
|
Removes the element <VAR>m</VAR> from the set <VAR>s</VAR>. Returns the new
|
|
set.
|
|
|
|
<DT><CODE>FLOAT(<VAR>i</VAR>)</CODE>
|
|
<DD>
|
|
Returns the floating point equivalent of the integer <VAR>i</VAR>.
|
|
|
|
<DT><CODE>HIGH(<VAR>a</VAR>)</CODE>
|
|
<DD>
|
|
Returns the index of the last member of <VAR>a</VAR>.
|
|
|
|
<DT><CODE>INC(<VAR>v</VAR>)</CODE>
|
|
<DD>
|
|
Increments the value in the variable <VAR>v</VAR>. Returns the new value.
|
|
|
|
<DT><CODE>INC(<VAR>v</VAR>,<VAR>i</VAR>)</CODE>
|
|
<DD>
|
|
Increments the value in the variable <VAR>v</VAR> by <VAR>i</VAR>. Returns the
|
|
new value.
|
|
|
|
<DT><CODE>INCL(<VAR>m</VAR>,<VAR>s</VAR>)</CODE>
|
|
<DD>
|
|
Adds the element <VAR>m</VAR> to the set <VAR>s</VAR> if it is not already
|
|
there. Returns the new set.
|
|
|
|
<DT><CODE>MAX(<VAR>t</VAR>)</CODE>
|
|
<DD>
|
|
Returns the maximum value of the type <VAR>t</VAR>.
|
|
|
|
<DT><CODE>MIN(<VAR>t</VAR>)</CODE>
|
|
<DD>
|
|
Returns the minimum value of the type <VAR>t</VAR>.
|
|
|
|
<DT><CODE>ODD(<VAR>i</VAR>)</CODE>
|
|
<DD>
|
|
Returns boolean TRUE if <VAR>i</VAR> is an odd number.
|
|
|
|
<DT><CODE>ORD(<VAR>x</VAR>)</CODE>
|
|
<DD>
|
|
Returns the ordinal value of its argument. For example, the ordinal
|
|
value of a character is its ASCII value (on machines supporting the
|
|
ASCII character set). <VAR>x</VAR> must be of an ordered type, which include
|
|
integral, character and enumerated types.
|
|
|
|
<DT><CODE>SIZE(<VAR>x</VAR>)</CODE>
|
|
<DD>
|
|
Returns the size of its argument. <VAR>x</VAR> can be a variable or a type.
|
|
|
|
<DT><CODE>TRUNC(<VAR>r</VAR>)</CODE>
|
|
<DD>
|
|
Returns the integral part of <VAR>r</VAR>.
|
|
|
|
<DT><CODE>VAL(<VAR>t</VAR>,<VAR>i</VAR>)</CODE>
|
|
<DD>
|
|
Returns the member of the type <VAR>t</VAR> whose ordinal value is <VAR>i</VAR>.
|
|
</DL>
|
|
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> Sets and their operations are not yet supported, so
|
|
GDB treats the use of procedures <CODE>INCL</CODE> and <CODE>EXCL</CODE> as
|
|
an error.
|
|
</BLOCKQUOTE>
|
|
|
|
<P>
|
|
<A NAME="IDX379"></A>
|
|
|
|
|
|
<H4><A NAME="SEC84" HREF="gdb_toc.html#TOC84">Constants</A></H4>
|
|
|
|
<P>
|
|
GDB allows you to express the constants of Modula-2 in the following
|
|
ways:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
|
|
<LI>
|
|
|
|
Integer constants are simply a sequence of digits. When used in an
|
|
expression, a constant is interpreted to be type-compatible with the
|
|
rest of the expression. Hexadecimal integers are specified by a
|
|
trailing <SAMP>`H'</SAMP>, and octal integers by a trailing <SAMP>`B'</SAMP>.
|
|
|
|
<LI>
|
|
|
|
Floating point constants appear as a sequence of digits, followed by a
|
|
decimal point and another sequence of digits. An optional exponent can
|
|
then be specified, in the form <SAMP>`E[+|-]<VAR>nnn</VAR>'</SAMP>, where
|
|
<SAMP>`[+|-]<VAR>nnn</VAR>'</SAMP> is the desired exponent. All of the
|
|
digits of the floating point constant must be valid decimal (base 10)
|
|
digits.
|
|
|
|
<LI>
|
|
|
|
Character constants consist of a single character enclosed by a pair of
|
|
like quotes, either single (<CODE>'</CODE>) or double (<CODE>"</CODE>). They may
|
|
also be expressed by their ordinal value (their ASCII value, usually)
|
|
followed by a <SAMP>`C'</SAMP>.
|
|
|
|
<LI>
|
|
|
|
String constants consist of a sequence of characters enclosed by a
|
|
pair of like quotes, either single (<CODE>'</CODE>) or double (<CODE>"</CODE>).
|
|
Escape sequences in the style of C are also allowed. See section <A HREF="gdb.html#SEC75">C and C++ constants</A>, for a brief explanation of escape
|
|
sequences.
|
|
|
|
<LI>
|
|
|
|
Enumerated constants consist of an enumerated identifier.
|
|
|
|
<LI>
|
|
|
|
Boolean constants consist of the identifiers <CODE>TRUE</CODE> and
|
|
<CODE>FALSE</CODE>.
|
|
|
|
<LI>
|
|
|
|
Pointer constants consist of integral values only.
|
|
|
|
<LI>
|
|
|
|
Set constants are not yet supported.
|
|
</UL>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC85" HREF="gdb_toc.html#TOC85">Modula-2 defaults</A></H4>
|
|
<P>
|
|
<A NAME="IDX380"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If type and range checking are set automatically by GDB, they
|
|
both default to <CODE>on</CODE> whenever the working language changes to
|
|
Modula-2. This happens regardless of whether you, or GDB,
|
|
selected the working language.
|
|
|
|
</P>
|
|
<P>
|
|
If you allow GDB to set the language automatically, then entering
|
|
code compiled from a file whose name ends with <TT>`.mod'</TT> sets the
|
|
working language to Modula-2. See section <A HREF="gdb.html#SEC67">Having GDB infer the source language</A>, for further details.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC86" HREF="gdb_toc.html#TOC86">Deviations from standard Modula-2</A></H4>
|
|
<P>
|
|
<A NAME="IDX381"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A few changes have been made to make Modula-2 programs easier to debug.
|
|
This is done primarily via loosening its type strictness:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Unlike in standard Modula-2, pointer constants can be formed by
|
|
integers. This allows you to modify pointer variables during
|
|
debugging. (In standard Modula-2, the actual address contained in a
|
|
pointer variable is hidden from you; it can only be modified
|
|
through direct assignment to another pointer variable or expression that
|
|
returned a pointer.)
|
|
|
|
<LI>
|
|
|
|
C escape sequences can be used in strings and characters to represent
|
|
non-printable characters. GDB prints out strings with these
|
|
escape sequences embedded. Single non-printable characters are
|
|
printed using the <SAMP>`CHR(<VAR>nnn</VAR>)'</SAMP> format.
|
|
|
|
<LI>
|
|
|
|
The assignment operator (<CODE>:=</CODE>) returns the value of its right-hand
|
|
argument.
|
|
|
|
<LI>
|
|
|
|
All built-in procedures both modify <EM>and</EM> return their argument.
|
|
</UL>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC87" HREF="gdb_toc.html#TOC87">Modula-2 type and range checks</A></H4>
|
|
<P>
|
|
<A NAME="IDX382"></A>
|
|
|
|
</P>
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> in this release, GDB does not yet perform type or
|
|
range checking.
|
|
</BLOCKQUOTE>
|
|
|
|
<P>
|
|
GDB considers two Modula-2 variables type equivalent if:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
They are of types that have been declared equivalent via a <CODE>TYPE
|
|
<VAR>t1</VAR> = <VAR>t2</VAR></CODE> statement
|
|
|
|
<LI>
|
|
|
|
They have been declared on the same line. (Note: This is true of the
|
|
GNU Modula-2 compiler, but it may not be true of other compilers.)
|
|
</UL>
|
|
|
|
<P>
|
|
As long as type checking is enabled, any attempt to combine variables
|
|
whose types are not equivalent is an error.
|
|
|
|
</P>
|
|
<P>
|
|
Range checking is done on all mathematical operations, assignment, array
|
|
index bounds, and all built-in functions and procedures.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC88" HREF="gdb_toc.html#TOC88">The scope operators <CODE>::</CODE> and <CODE>.</CODE></A></H4>
|
|
<P>
|
|
<A NAME="IDX383"></A>
|
|
<A NAME="IDX384"></A>
|
|
<A NAME="IDX385"></A>
|
|
<A NAME="IDX386"></A>
|
|
|
|
</P>
|
|
<P>
|
|
There are a few subtle differences between the Modula-2 scope operator
|
|
(<CODE>.</CODE>) and the GDB scope operator (<CODE>::</CODE>). The two have
|
|
similar syntax:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
|
|
<VAR>module</VAR> . <VAR>id</VAR>
|
|
<VAR>scope</VAR> :: <VAR>id</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
where <VAR>scope</VAR> is the name of a module or a procedure,
|
|
<VAR>module</VAR> the name of a module, and <VAR>id</VAR> is any declared
|
|
identifier within your program, except another module.
|
|
|
|
</P>
|
|
<P>
|
|
Using the <CODE>::</CODE> operator makes GDB search the scope
|
|
specified by <VAR>scope</VAR> for the identifier <VAR>id</VAR>. If it is not
|
|
found in the specified scope, then GDB searches all scopes
|
|
enclosing the one specified by <VAR>scope</VAR>.
|
|
|
|
</P>
|
|
<P>
|
|
Using the <CODE>.</CODE> operator makes GDB search the current scope for
|
|
the identifier specified by <VAR>id</VAR> that was imported from the
|
|
definition module specified by <VAR>module</VAR>. With this operator, it is
|
|
an error if the identifier <VAR>id</VAR> was not imported from definition
|
|
module <VAR>module</VAR>, or if <VAR>id</VAR> is not an identifier in
|
|
<VAR>module</VAR>.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC89" HREF="gdb_toc.html#TOC89">GDB and Modula-2</A></H4>
|
|
|
|
<P>
|
|
Some GDB commands have little use when debugging Modula-2 programs.
|
|
Five subcommands of <CODE>set print</CODE> and <CODE>show print</CODE> apply
|
|
specifically to C and C++: <SAMP>`vtbl'</SAMP>, <SAMP>`demangle'</SAMP>,
|
|
<SAMP>`asm-demangle'</SAMP>, <SAMP>`object'</SAMP>, and <SAMP>`union'</SAMP>. The first four
|
|
apply to C++, and the last to the C <CODE>union</CODE> type, which has no direct
|
|
analogue in Modula-2.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>@</CODE> operator (see section <A HREF="gdb.html#SEC52">Expressions</A>), while available
|
|
while using any language, is not useful with Modula-2. Its
|
|
intent is to aid the debugging of <STRONG>dynamic arrays</STRONG>, which cannot be
|
|
created in Modula-2 as they can in C or C++. However, because an
|
|
address can be specified by an integral constant, the construct
|
|
<SAMP>`{<VAR>type</VAR>}<VAR>adrexp</VAR>'</SAMP> is still useful. (see section <A HREF="gdb.html#SEC52">Expressions</A>)
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX387"></A>
|
|
In GDB scripts, the Modula-2 inequality operator <CODE>#</CODE> is
|
|
interpreted as the beginning of a comment. Use <CODE><></CODE> instead.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC90" HREF="gdb_toc.html#TOC90">Examining the Symbol Table</A></H1>
|
|
|
|
<P>
|
|
The commands described in this section allow you to inquire about the
|
|
symbols (names of variables, functions and types) defined in your
|
|
program. This information is inherent in the text of your program and
|
|
does not change as your program executes. GDB finds it in your
|
|
program's symbol table, in the file indicated when you started GDB
|
|
(see section <A HREF="gdb.html#SEC7">Choosing files</A>), or by one of the
|
|
file-management commands (see section <A HREF="gdb.html#SEC99">Commands to specify files</A>).
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX388"></A>
|
|
<A NAME="IDX389"></A>
|
|
<A NAME="IDX390"></A>
|
|
Occasionally, you may need to refer to symbols that contain unusual
|
|
characters, which GDB ordinarily treats as word delimiters. The
|
|
most frequent case is in referring to static variables in other
|
|
source files (see section <A HREF="gdb.html#SEC53">Program variables</A>). File names
|
|
are recorded in object files as debugging symbols, but GDB would
|
|
ordinarily parse a typical file name, like <TT>`foo.c'</TT>, as the three words
|
|
<SAMP>`foo'</SAMP> <SAMP>`.'</SAMP> <SAMP>`c'</SAMP>. To allow GDB to recognize
|
|
<SAMP>`foo.c'</SAMP> as a single symbol, enclose it in single quotes; for example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
p 'foo.c'::x
|
|
</PRE>
|
|
|
|
<P>
|
|
looks up the value of <CODE>x</CODE> in the scope of the file <TT>`foo.c'</TT>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info address <VAR>symbol</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX391"></A>
|
|
|
|
Describe where the data for <VAR>symbol</VAR> is stored. For a register
|
|
variable, this says which register it is kept in. For a non-register
|
|
local variable, this prints the stack-frame offset at which the variable
|
|
is always stored.
|
|
|
|
Note the contrast with <SAMP>`print &<VAR>symbol</VAR>'</SAMP>, which does not work
|
|
at all for a register variable, and for a stack local variable prints
|
|
the exact address of the current instantiation of the variable.
|
|
|
|
<A NAME="IDX392"></A>
|
|
<DT><CODE>whatis <VAR>exp</VAR></CODE>
|
|
<DD>
|
|
Print the data type of expression <VAR>exp</VAR>. <VAR>exp</VAR> is not
|
|
actually evaluated, and any side-effecting operations (such as
|
|
assignments or function calls) inside it do not take place.
|
|
See section <A HREF="gdb.html#SEC52">Expressions</A>.
|
|
|
|
<DT><CODE>whatis</CODE>
|
|
<DD>
|
|
Print the data type of <CODE>$</CODE>, the last value in the value history.
|
|
|
|
<A NAME="IDX393"></A>
|
|
<DT><CODE>ptype <VAR>typename</VAR></CODE>
|
|
<DD>
|
|
Print a description of data type <VAR>typename</VAR>. <VAR>typename</VAR> may be
|
|
the name of a type, or for C code it may have the form
|
|
<SAMP>`class <VAR>class-name</VAR>'</SAMP>,
|
|
<SAMP>`struct <VAR>struct-tag</VAR>'</SAMP>, <SAMP>`union <VAR>union-tag</VAR>'</SAMP> or
|
|
<SAMP>`enum <VAR>enum-tag</VAR>'</SAMP>.
|
|
|
|
<DT><CODE>ptype <VAR>exp</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>ptype</CODE>
|
|
<DD>
|
|
Print a description of the type of expression <VAR>exp</VAR>. <CODE>ptype</CODE>
|
|
differs from <CODE>whatis</CODE> by printing a detailed description, instead
|
|
of just the name of the type.
|
|
|
|
For example, for this variable declaration:
|
|
|
|
|
|
<PRE>
|
|
struct complex {double real; double imag;} v;
|
|
</PRE>
|
|
|
|
the two commands give this output:
|
|
|
|
|
|
<PRE>
|
|
(gdb) whatis v
|
|
type = struct complex
|
|
(gdb) ptype v
|
|
type = struct complex {
|
|
double real;
|
|
double imag;
|
|
}
|
|
</PRE>
|
|
|
|
As with <CODE>whatis</CODE>, using <CODE>ptype</CODE> without an argument refers to
|
|
the type of <CODE>$</CODE>, the last value in the value history.
|
|
|
|
<A NAME="IDX394"></A>
|
|
<DT><CODE>info types <VAR>regexp</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>info types</CODE>
|
|
<DD>
|
|
Print a brief description of all types whose name matches <VAR>regexp</VAR>
|
|
(or all types in your program, if you supply no argument). Each
|
|
complete typename is matched as though it were a complete line; thus,
|
|
<SAMP>`i type value'</SAMP> gives information on all types in your program whose
|
|
name includes the string <CODE>value</CODE>, but <SAMP>`i type ^value$'</SAMP> gives
|
|
information only on types whose complete name is <CODE>value</CODE>.
|
|
|
|
This command differs from <CODE>ptype</CODE> in two ways: first, like
|
|
<CODE>whatis</CODE>, it does not print a detailed description; second, it
|
|
lists all source files where a type is defined.
|
|
|
|
<A NAME="IDX395"></A>
|
|
<DT><CODE>info source</CODE>
|
|
<DD>
|
|
Show the name of the current source file--that is, the source file for
|
|
the function containing the current point of execution--and the language
|
|
it was written in.
|
|
|
|
<A NAME="IDX396"></A>
|
|
<DT><CODE>info sources</CODE>
|
|
<DD>
|
|
Print the names of all source files in your program for which there is
|
|
debugging information, organized into two lists: files whose symbols
|
|
have already been read, and files whose symbols will be read when needed.
|
|
|
|
<A NAME="IDX397"></A>
|
|
<DT><CODE>info functions</CODE>
|
|
<DD>
|
|
Print the names and data types of all defined functions.
|
|
|
|
<DT><CODE>info functions <VAR>regexp</VAR></CODE>
|
|
<DD>
|
|
Print the names and data types of all defined functions
|
|
whose names contain a match for regular expression <VAR>regexp</VAR>.
|
|
Thus, <SAMP>`info fun step'</SAMP> finds all functions whose names
|
|
include <CODE>step</CODE>; <SAMP>`info fun ^step'</SAMP> finds those whose names
|
|
start with <CODE>step</CODE>.
|
|
|
|
<A NAME="IDX398"></A>
|
|
<DT><CODE>info variables</CODE>
|
|
<DD>
|
|
Print the names and data types of all variables that are declared
|
|
outside of functions (i.e., excluding local variables).
|
|
|
|
<DT><CODE>info variables <VAR>regexp</VAR></CODE>
|
|
<DD>
|
|
Print the names and data types of all variables (except for local
|
|
variables) whose names contain a match for regular expression
|
|
<VAR>regexp</VAR>.
|
|
|
|
<A NAME="IDX399"></A>
|
|
Some systems allow individual object files that make up your program to
|
|
be replaced without stopping and restarting your program.
|
|
For example, in VxWorks you can simply recompile a defective object file
|
|
and keep on running.
|
|
If you are running on one of these systems, you can allow GDB to
|
|
reload the symbols for automatically relinked modules:
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set symbol-reloading on</CODE>
|
|
<DD>
|
|
<A NAME="IDX400"></A>
|
|
|
|
Replace symbol definitions for the corresponding source file when an
|
|
object file with a particular name is seen again.
|
|
|
|
<DT><CODE>set symbol-reloading off</CODE>
|
|
<DD>
|
|
Do not replace symbol definitions when re-encountering object files of
|
|
the same name. This is the default state; if you are not running on a
|
|
system that permits automatically relinking modules, you should leave
|
|
<CODE>symbol-reloading</CODE> off, since otherwise GDB may discard symbols
|
|
when linking large programs, that may contain several modules (from
|
|
different directories or libraries) with the same name.
|
|
|
|
<A NAME="IDX401"></A>
|
|
<DT><CODE>show symbol-reloading</CODE>
|
|
<DD>
|
|
Show the current <CODE>on</CODE> or <CODE>off</CODE> setting.
|
|
</DL>
|
|
|
|
<A NAME="IDX402"></A>
|
|
<A NAME="IDX403"></A>
|
|
<A NAME="IDX404"></A>
|
|
<A NAME="IDX405"></A>
|
|
<DT><CODE>maint print symbols <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>maint print psymbols <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>maint print msymbols <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
Write a dump of debugging symbol data into the file <VAR>filename</VAR>.
|
|
These commands are used to debug the GDB symbol-reading code. Only
|
|
symbols with debugging data are included. If you use <SAMP>`maint print
|
|
symbols'</SAMP>, GDB includes all the symbols for which it has already
|
|
collected full details: that is, <VAR>filename</VAR> reflects symbols for
|
|
only those files whose symbols GDB has read. You can use the
|
|
command <CODE>info sources</CODE> to find out which files these are. If you
|
|
use <SAMP>`maint print psymbols'</SAMP> instead, the dump shows information about
|
|
symbols that GDB only knows partially--that is, symbols defined in
|
|
files that GDB has skimmed, but not yet read completely. Finally,
|
|
<SAMP>`maint print msymbols'</SAMP> dumps just the minimal symbol information
|
|
required for each object file from which GDB has read some symbols.
|
|
See section <A HREF="gdb.html#SEC99">Commands to specify files</A>, for a discussion of how
|
|
GDB reads symbols (in the description of <CODE>symbol-file</CODE>).
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC91" HREF="gdb_toc.html#TOC91">Altering Execution</A></H1>
|
|
|
|
<P>
|
|
Once you think you have found an error in your program, you might want to
|
|
find out for certain whether correcting the apparent error would lead to
|
|
correct results in the rest of the run. You can find the answer by
|
|
experiment, using the GDB features for altering execution of the
|
|
program.
|
|
|
|
</P>
|
|
<P>
|
|
For example, you can store new values into variables or memory
|
|
locations,
|
|
give your program a signal, restart it
|
|
at a different address, or even return prematurely from a function.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC92" HREF="gdb_toc.html#TOC92">Assignment to variables</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX406"></A>
|
|
<A NAME="IDX407"></A>
|
|
To alter the value of a variable, evaluate an assignment expression.
|
|
See section <A HREF="gdb.html#SEC52">Expressions</A>. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
print x=4
|
|
</PRE>
|
|
|
|
<P>
|
|
stores the value 4 into the variable <CODE>x</CODE>, and then prints the
|
|
value of the assignment expression (which is 4).
|
|
See section <A HREF="gdb.html#SEC63">Using GDB with Different Languages</A>, for more
|
|
information on operators in supported languages.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX408"></A>
|
|
<A NAME="IDX409"></A>
|
|
If you are not interested in seeing the value of the assignment, use the
|
|
<CODE>set</CODE> command instead of the <CODE>print</CODE> command. <CODE>set</CODE> is
|
|
really the same as <CODE>print</CODE> except that the expression's value is
|
|
not printed and is not put in the value history (see section <A HREF="gdb.html#SEC59">Value history</A>). The expression is evaluated only for its effects.
|
|
|
|
</P>
|
|
<P>
|
|
If the beginning of the argument string of the <CODE>set</CODE> command
|
|
appears identical to a <CODE>set</CODE> subcommand, use the <CODE>set
|
|
variable</CODE> command instead of just <CODE>set</CODE>. This command is identical
|
|
to <CODE>set</CODE> except for its lack of subcommands. For example, if
|
|
your program has a variable <CODE>width</CODE>, you get
|
|
an error if you try to set a new value with just <SAMP>`set width=13'</SAMP>,
|
|
because GDB has the command <CODE>set width</CODE>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) whatis width
|
|
type = double
|
|
(gdb) p width
|
|
$4 = 13
|
|
(gdb) set width=47
|
|
Invalid syntax in expression.
|
|
</PRE>
|
|
|
|
<P>
|
|
The invalid expression, of course, is <SAMP>`=47'</SAMP>. In
|
|
order to actually set the program's variable <CODE>width</CODE>, use
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) set var width=47
|
|
</PRE>
|
|
|
|
<P>
|
|
GDB allows more implicit conversions in assignments than C; you can
|
|
freely store an integer value into a pointer variable or vice versa,
|
|
and you can convert any structure to any other structure that is the
|
|
same length or shorter.
|
|
|
|
</P>
|
|
<P>
|
|
To store values into arbitrary places in memory, use the <SAMP>`{...}'</SAMP>
|
|
construct to generate a value of specified type at a specified address
|
|
(see section <A HREF="gdb.html#SEC52">Expressions</A>). For example, <CODE>{int}0x83040</CODE> refers
|
|
to memory location <CODE>0x83040</CODE> as an integer (which implies a certain size
|
|
and representation in memory), and
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
set {int}0x83040 = 4
|
|
</PRE>
|
|
|
|
<P>
|
|
stores the value 4 into that memory location.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC93" HREF="gdb_toc.html#TOC93">Continuing at a different address</A></H2>
|
|
|
|
<P>
|
|
Ordinarily, when you continue your program, you do so at the place where
|
|
it stopped, with the <CODE>continue</CODE> command. You can instead continue at
|
|
an address of your own choosing, with the following commands:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>jump <VAR>linespec</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX410"></A>
|
|
|
|
Resume execution at line <VAR>linespec</VAR>. Execution stops again
|
|
immediately if there is a breakpoint there. See section <A HREF="gdb.html#SEC47">Printing source lines</A>, for a description of the different forms of
|
|
<VAR>linespec</VAR>.
|
|
|
|
The <CODE>jump</CODE> command does not change the current stack frame, or
|
|
the stack pointer, or the contents of any memory location or any
|
|
register other than the program counter. If line <VAR>linespec</VAR> is in
|
|
a different function from the one currently executing, the results may
|
|
be bizarre if the two functions expect different patterns of arguments or
|
|
of local variables. For this reason, the <CODE>jump</CODE> command requests
|
|
confirmation if the specified line is not in the function currently
|
|
executing. However, even bizarre results are predictable if you are
|
|
well acquainted with the machine-language code of your program.
|
|
|
|
<DT><CODE>jump *<VAR>address</VAR></CODE>
|
|
<DD>
|
|
Resume execution at the instruction at address <VAR>address</VAR>.
|
|
</DL>
|
|
|
|
<P>
|
|
You can get much the same effect as the <CODE>jump</CODE> command by storing a
|
|
new value into the register <CODE>$pc</CODE>. The difference is that this
|
|
does not start your program running; it only changes the address of where it
|
|
<EM>will</EM> run when you continue. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
set $pc = 0x485
|
|
</PRE>
|
|
|
|
<P>
|
|
makes the next <CODE>continue</CODE> command or stepping command execute at
|
|
address <CODE>0x485</CODE>, rather than at the address where your program stopped.
|
|
See section <A HREF="gdb.html#SEC37">Continuing and stepping</A>.
|
|
|
|
</P>
|
|
<P>
|
|
The most common occasion to use the <CODE>jump</CODE> command is to back up--
|
|
perhaps with more breakpoints set--over a portion of a program that has
|
|
already executed, in order to examine its execution in more detail.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC94" HREF="gdb_toc.html#TOC94">Giving your program a signal</A></H2>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>signal <VAR>signal</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX411"></A>
|
|
|
|
Resume execution where your program stopped, but immediately give it the
|
|
signal <VAR>signal</VAR>. <VAR>signal</VAR> can be the name or the number of a
|
|
signal. For example, on many systems <CODE>signal 2</CODE> and <CODE>signal
|
|
SIGINT</CODE> are both ways of sending an interrupt signal.
|
|
|
|
Alternatively, if <VAR>signal</VAR> is zero, continue execution without
|
|
giving a signal. This is useful when your program stopped on account of
|
|
a signal and would ordinary see the signal when resumed with the
|
|
<CODE>continue</CODE> command; <SAMP>`signal 0'</SAMP> causes it to resume without a
|
|
signal.
|
|
|
|
<CODE>signal</CODE> does not repeat when you press <KBD>RET</KBD> a second time
|
|
after executing the command.
|
|
</DL>
|
|
|
|
<P>
|
|
Invoking the <CODE>signal</CODE> command is not the same as invoking the
|
|
<CODE>kill</CODE> utility from the shell. Sending a signal with <CODE>kill</CODE>
|
|
causes GDB to decide what to do with the signal depending on
|
|
the signal handling tables (see section <A HREF="gdb.html#SEC38">Signals</A>). The <CODE>signal</CODE> command
|
|
passes the signal directly to your program.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC95" HREF="gdb_toc.html#TOC95">Returning from a function</A></H2>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>return</CODE>
|
|
<DD>
|
|
<A NAME="IDX412"></A>
|
|
<A NAME="IDX413"></A>
|
|
|
|
<DT><CODE>return <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
You can cancel execution of a function call with the <CODE>return</CODE>
|
|
command. If you give an
|
|
<VAR>expression</VAR> argument, its value is used as the function's return
|
|
value.
|
|
</DL>
|
|
|
|
<P>
|
|
When you use <CODE>return</CODE>, GDB discards the selected stack frame
|
|
(and all frames within it). You can think of this as making the
|
|
discarded frame return prematurely. If you wish to specify a value to
|
|
be returned, give that value as the argument to <CODE>return</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
This pops the selected stack frame (see section <A HREF="gdb.html#SEC43">Selecting a frame</A>), and any other frames inside of it, leaving its caller as the
|
|
innermost remaining frame. That frame becomes selected. The
|
|
specified value is stored in the registers used for returning values
|
|
of functions.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>return</CODE> command does not resume execution; it leaves the
|
|
program stopped in the state that would exist if the function had just
|
|
returned. In contrast, the <CODE>finish</CODE> command (see section <A HREF="gdb.html#SEC37">Continuing and stepping</A>) resumes execution until the
|
|
selected stack frame returns naturally.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC96" HREF="gdb_toc.html#TOC96">Calling program functions</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX414"></A>
|
|
<A NAME="IDX415"></A>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>call <VAR>expr</VAR></CODE>
|
|
<DD>
|
|
Evaluate the expression <VAR>expr</VAR> without displaying <CODE>void</CODE>
|
|
returned values.
|
|
</DL>
|
|
|
|
<P>
|
|
You can use this variant of the <CODE>print</CODE> command if you want to
|
|
execute a function from your program, but without cluttering the output
|
|
with <CODE>void</CODE> returned values. If the result is not void, it
|
|
is printed and saved in the value history.
|
|
|
|
</P>
|
|
<P>
|
|
A new user-controlled variable, <VAR>call_scratch_address</VAR>, specifies
|
|
the location of a scratch area to be used when GDB calls a
|
|
function in the target. This is necessary because the usual method
|
|
of putting the scratch area on the stack does not work in systems that
|
|
have separate instruction and data spaces.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC97" HREF="gdb_toc.html#TOC97">Patching programs</A></H2>
|
|
<P>
|
|
<A NAME="IDX416"></A>
|
|
<A NAME="IDX417"></A>
|
|
<A NAME="IDX418"></A>
|
|
|
|
</P>
|
|
<P>
|
|
By default, GDB opens the file containing your program's executable
|
|
code
|
|
(or the corefile)
|
|
read-only. This prevents accidental alterations
|
|
to machine code; but it also prevents you from intentionally patching
|
|
your program's binary.
|
|
|
|
</P>
|
|
<P>
|
|
If you'd like to be able to patch the binary, you can specify that
|
|
explicitly with the <CODE>set write</CODE> command. For example, you might
|
|
want to turn on internal debugging flags, or even to make emergency
|
|
repairs.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set write on</CODE>
|
|
<DD>
|
|
<A NAME="IDX419"></A>
|
|
|
|
<DT><CODE>set write off</CODE>
|
|
<DD>
|
|
If you specify <SAMP>`set write on'</SAMP>, GDB opens executable
|
|
and core
|
|
files for both reading and writing; if you specify <SAMP>`set write
|
|
off'</SAMP> (the default), GDB opens them read-only.
|
|
|
|
If you have already loaded a file, you must load it again (using the
|
|
<CODE>exec-file</CODE>
|
|
or <CODE>core-file</CODE>
|
|
command) after changing <CODE>set write</CODE>, for your new setting to take
|
|
effect.
|
|
|
|
<DT><CODE>show write</CODE>
|
|
<DD>
|
|
<A NAME="IDX420"></A>
|
|
Display whether executable files
|
|
and core files
|
|
are opened for writing as well as reading.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC98" HREF="gdb_toc.html#TOC98">GDB Files</A></H1>
|
|
|
|
<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>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC99" HREF="gdb_toc.html#TOC99">Commands to specify files</A></H2>
|
|
<P>
|
|
<A NAME="IDX421"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX422"></A>
|
|
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.html#SEC5">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>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>file <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX423"></A>
|
|
<A NAME="IDX424"></A>
|
|
|
|
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.
|
|
|
|
On systems with memory-mapped files, an auxiliary file
|
|
<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.
|
|
|
|
<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.
|
|
|
|
<A NAME="IDX425"></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.
|
|
|
|
<A NAME="IDX426"></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.
|
|
|
|
<CODE>symbol-file</CODE> with no argument clears out GDB information on your
|
|
program's symbol table.
|
|
|
|
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.
|
|
|
|
<CODE>symbol-file</CODE> does not repeat if you press <KBD>RET</KBD> 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 <CODE>gcc</CODE>
|
|
you can generate debugging information for optimized code.
|
|
|
|
On some kinds of object files, 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.
|
|
|
|
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.html#SEC144">Optional warnings and messages</A>.)
|
|
|
|
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.
|
|
|
|
<A NAME="IDX427"></A>
|
|
<A NAME="IDX428"></A>
|
|
<A NAME="IDX429"></A>
|
|
<A NAME="IDX430"></A>
|
|
<A NAME="IDX431"></A>
|
|
<A NAME="IDX432"></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.
|
|
|
|
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.
|
|
|
|
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 <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.
|
|
|
|
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.
|
|
|
|
<A NAME="IDX433"></A>
|
|
<A NAME="IDX434"></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.
|
|
|
|
<CODE>core-file</CODE> 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 <CODE>kill</CODE> command
|
|
(see section <A HREF="gdb.html#SEC23">Killing the child process</A>).
|
|
|
|
<A NAME="IDX435"></A>
|
|
<DT><CODE>load <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
Depending on what remote debugging facilities are configured into
|
|
GDB, the <CODE>load</CODE> command may be available. Where it exists, it
|
|
is meant to make <VAR>filename</VAR> (an executable) available for debugging
|
|
on the remote system--by downloading, or dynamic linking, for example.
|
|
<CODE>load</CODE> also records the <VAR>filename</VAR> symbol table in GDB, like
|
|
the <CODE>add-symbol-file</CODE> command.
|
|
|
|
If your GDB does not have a <CODE>load</CODE> command, attempting to
|
|
execute it gets the error message "<CODE>You can't do that when your
|
|
target is ...</CODE>"
|
|
|
|
The file is loaded at whatever address is specified in the executable.
|
|
For some object file formats, you can specify the load address when you
|
|
link the program; for other formats, like a.out, the object file format
|
|
specifies a fixed address.
|
|
|
|
On VxWorks, <CODE>load</CODE> links <VAR>filename</VAR> dynamically on the
|
|
current target system as well as adding its symbols in GDB.
|
|
|
|
<A NAME="IDX436"></A>
|
|
With the Nindy interface to an Intel 960 board, <CODE>load</CODE>
|
|
downloads <VAR>filename</VAR> to the 960 as well as adding its symbols in
|
|
GDB.
|
|
|
|
<A NAME="IDX437"></A>
|
|
<A NAME="IDX438"></A>
|
|
<A NAME="IDX439"></A>
|
|
<A NAME="IDX440"></A>
|
|
When you select remote debugging to a Hitachi SH, H8/300, or H8/500 board
|
|
(see section <A HREF="gdb.html#SEC132">GDB and Hitachi microprocessors</A>),
|
|
the <CODE>load</CODE> command downloads your program to the Hitachi board and also
|
|
opens it as the current executable target for GDB on your host
|
|
(like the <CODE>file</CODE> command).
|
|
|
|
<CODE>load</CODE> does not repeat if you press <KBD>RET</KBD> again after using it.
|
|
|
|
<A NAME="IDX441"></A>
|
|
<A NAME="IDX442"></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>
|
|
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 specify <VAR>address</VAR> as an expression.
|
|
|
|
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.
|
|
|
|
<CODE>add-symbol-file</CODE> does not repeat if you press <KBD>RET</KBD> after using it.
|
|
|
|
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>.
|
|
|
|
<A NAME="IDX443"></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.
|
|
|
|
<A NAME="IDX444"></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 "info files" command lists all the sections and their
|
|
addresses.
|
|
|
|
<A NAME="IDX445"></A>
|
|
<A NAME="IDX446"></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.html#SEC101">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.
|
|
</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="IDX447"></A>
|
|
GDB supports SunOS, SVr4, Irix 5, and IBM RS/6000 shared libraries.
|
|
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>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>info share</CODE>
|
|
<DD>
|
|
<A NAME="IDX448"></A>
|
|
<A NAME="IDX449"></A>
|
|
|
|
<DT><CODE>info sharedlibrary</CODE>
|
|
<DD>
|
|
Print the names of the shared libraries which are currently loaded.
|
|
|
|
<A NAME="IDX450"></A>
|
|
<A NAME="IDX451"></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>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC100" HREF="gdb_toc.html#TOC100">Errors reading symbol files</A></H2>
|
|
|
|
<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.html#SEC144">Optional warnings and messages</A>).
|
|
|
|
</P>
|
|
<P>
|
|
The messages currently printed, and their meanings, include:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>inner block not inside outer block in <VAR>symbol</VAR></CODE>
|
|
<DD>
|
|
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.
|
|
|
|
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.
|
|
|
|
<DT><CODE>block at <VAR>address</VAR> out of order</CODE>
|
|
<DD>
|
|
The symbol information for symbol scope blocks should occur in
|
|
order of increasing addresses. This error indicates that it does not
|
|
do so.
|
|
|
|
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.html#SEC144">Optional warnings and messages</A>.)
|
|
|
|
<DT><CODE>bad block start address patched</CODE>
|
|
<DD>
|
|
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.
|
|
|
|
GDB circumvents the problem by treating the symbol scope block as
|
|
starting on the previous source line.
|
|
|
|
<DT><CODE>bad string table offset in symbol <VAR>n</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX452"></A>
|
|
Symbol number <VAR>n</VAR> contains a pointer into the string table which is
|
|
larger than the size of the string table.
|
|
|
|
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.
|
|
|
|
<DT><CODE>unknown symbol type <CODE>0x<VAR>nn</VAR></CODE></CODE>
|
|
<DD>
|
|
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 misunderstood
|
|
information, in hexadecimal.
|
|
|
|
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.
|
|
|
|
<DT><CODE>stub type has NULL name</CODE>
|
|
<DD>
|
|
GDB could not find the full definition for
|
|
a struct or class.
|
|
|
|
<DT><CODE>const/volatile indicator missing (ok if using g++ v1.x), got...</CODE>
|
|
<DD>
|
|
The symbol information for a C++ member function is missing some
|
|
information that recent versions of the compiler should have output
|
|
for it.
|
|
|
|
<DT><CODE>info mismatch between compiler and debugger</CODE>
|
|
<DD>
|
|
GDB could not parse a type specification output by the compiler.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC101" HREF="gdb_toc.html#TOC101">Specifying a Debugging Target</A></H1>
|
|
<P>
|
|
<A NAME="IDX453"></A>
|
|
<A NAME="IDX454"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A <STRONG>target</STRONG> is the execution environment occupied by your program.
|
|
Often, GDB runs in the same host environment as your program; in
|
|
that case, the debugging target is specified as a side effect when you
|
|
use the <CODE>file</CODE> or <CODE>core</CODE> commands. When you need more
|
|
flexibility--for example, running GDB on a physically separate
|
|
host, or controlling a standalone system over a serial port or a
|
|
realtime system over a TCP/IP connection--you
|
|
can use the <CODE>target</CODE> command to specify one of the target types
|
|
configured for GDB (see section <A HREF="gdb.html#SEC103">Commands for managing targets</A>).
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC102" HREF="gdb_toc.html#TOC102">Active targets</A></H2>
|
|
<P>
|
|
<A NAME="IDX455"></A>
|
|
<A NAME="IDX456"></A>
|
|
<A NAME="IDX457"></A>
|
|
|
|
</P>
|
|
<P>
|
|
There are three classes of targets: processes, core files, and
|
|
executable files. GDB can work concurrently on up to three active
|
|
targets, one in each class. This allows you to (for example) start a
|
|
process and inspect its activity without abandoning your work on a core
|
|
file.
|
|
|
|
</P>
|
|
<P>
|
|
For example, if you execute <SAMP>`gdb a.out'</SAMP>, then the executable file
|
|
<CODE>a.out</CODE> is the only active target. If you designate a core file as
|
|
well--presumably from a prior run that crashed and coredumped--then
|
|
GDB has two active targets and uses them in tandem, looking
|
|
first in the corefile target, then in the executable file, to satisfy
|
|
requests for memory addresses. (Typically, these two classes of target
|
|
are complementary, since core files contain only a program's
|
|
read-write memory--variables and so on--plus machine status, while
|
|
executable files contain only the program text and initialized data.)
|
|
|
|
</P>
|
|
<P>
|
|
When you type <CODE>run</CODE>, your executable file becomes an active process
|
|
target as well. When a process target is active, all GDB commands
|
|
requesting memory addresses refer to that target; addresses in an
|
|
active core file or
|
|
executable file target are obscured while the process
|
|
target is active.
|
|
|
|
</P>
|
|
<P>
|
|
Use the <CODE>core-file</CODE> and <CODE>exec-file</CODE> commands to select a
|
|
new core file or executable target (see section <A HREF="gdb.html#SEC99">Commands to specify files</A>). To specify as a target a process that is already running, use
|
|
the <CODE>attach</CODE> command (see section <A HREF="gdb.html#SEC22">Debugging an already-running process</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC103" HREF="gdb_toc.html#TOC103">Commands for managing targets</A></H2>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>target <VAR>type</VAR> <VAR>parameters</VAR></CODE>
|
|
<DD>
|
|
Connects the GDB host environment to a target
|
|
machine or process. A target is typically a protocol for talking to
|
|
debugging facilities. You use the argument <VAR>type</VAR> to specify the
|
|
type or protocol of the target machine.
|
|
|
|
Further <VAR>parameters</VAR> are interpreted by the target protocol, but
|
|
typically include things like device names or host names to connect
|
|
with, process numbers, and baud rates.
|
|
|
|
The <CODE>target</CODE> command does not repeat if you press <KBD>RET</KBD> again
|
|
after executing the command.
|
|
|
|
<A NAME="IDX458"></A>
|
|
<DT><CODE>help target</CODE>
|
|
<DD>
|
|
Displays the names of all targets available. To display targets
|
|
currently selected, use either <CODE>info target</CODE> or <CODE>info files</CODE>
|
|
(see section <A HREF="gdb.html#SEC99">Commands to specify files</A>).
|
|
|
|
<DT><CODE>help target <VAR>name</VAR></CODE>
|
|
<DD>
|
|
Describe a particular target, including any parameters necessary to
|
|
select it.
|
|
|
|
<A NAME="IDX459"></A>
|
|
<DT><CODE>set gnutarget <VAR>args</VAR></CODE>
|
|
<DD>
|
|
GDBuses its own library BFD to read your files. GDB
|
|
knows whether it is reading an <STRONG>executable</STRONG>,
|
|
a <STRONG>core</STRONG>, or a <STRONG>.o</STRONG> file, however you can specify the file format
|
|
with the <CODE>set gnutarget</CODE> command. Unlike most <CODE>target</CODE> commands,
|
|
with <CODE>gnutarget</CODE> the <CODE>target</CODE> refers to a program, not a machine.
|
|
|
|
<EM>Warning:</EM> To specify a file format with <CODE>set gnutarget</CODE>,
|
|
you must know the actual BFD name.
|
|
|
|
See section <A HREF="gdb.html#SEC99">Commands to specify files</A>.
|
|
|
|
<A NAME="IDX460"></A>
|
|
<DT><CODE>show gnutarget</CODE>
|
|
<DD>
|
|
Use the <CODE>show gnutarget</CODE> command to display what file format
|
|
<CODE>gnutarget</CODE> is set to read. If you have not set <CODE>gnutarget</CODE>,
|
|
GDB will determine the file format for each file automatically
|
|
and <CODE>show gnutarget</CODE> displays <CODE>The current BDF target is "auto"</CODE>.
|
|
</DL>
|
|
|
|
<P>
|
|
Here are some common targets (available, or not, depending on the GDB
|
|
configuration):
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>target exec <VAR>program</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX461"></A>
|
|
|
|
An executable file. <SAMP>`target exec <VAR>program</VAR>'</SAMP> is the same as
|
|
<SAMP>`exec-file <VAR>program</VAR>'</SAMP>.
|
|
|
|
<A NAME="IDX462"></A>
|
|
<DT><CODE>target core <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
A core dump file. <SAMP>`target core <VAR>filename</VAR>'</SAMP> is the same as
|
|
<SAMP>`core-file <VAR>filename</VAR>'</SAMP>.
|
|
|
|
<A NAME="IDX463"></A>
|
|
<DT><CODE>target remote <VAR>dev</VAR></CODE>
|
|
<DD>
|
|
Remote serial target in GDB-specific protocol. The argument <VAR>dev</VAR>
|
|
specifies what serial device to use for the connection (e.g.
|
|
<TT>`/dev/ttya'</TT>). See section <A HREF="gdb.html#SEC105">Remote debugging</A>. <CODE>target remote</CODE>
|
|
now supports the <CODE>load</CODE> command. This is only useful if you have
|
|
some other way of getting the stub to the target system, and you can put
|
|
it somewhere in memory where it won't get clobbered by the download.
|
|
|
|
<A NAME="IDX464"></A>
|
|
<DT><CODE>target sim</CODE>
|
|
<DD>
|
|
CPU simulator. See section <A HREF="gdb.html#SEC137">Simulated CPU target</A>.
|
|
|
|
<A NAME="IDX465"></A>
|
|
<DT><CODE>target udi <VAR>keyword</VAR></CODE>
|
|
<DD>
|
|
Remote AMD29K target, using the AMD UDI protocol. The <VAR>keyword</VAR>
|
|
argument specifies which 29K board or simulator to use. See section <A HREF="gdb.html#SEC117">The UDI protocol for AMD29K</A>.
|
|
|
|
<A NAME="IDX466"></A>
|
|
<DT><CODE>target amd-eb <VAR>dev</VAR> <VAR>speed</VAR> <VAR>PROG</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX467"></A>
|
|
Remote PC-resident AMD EB29K board, attached over serial lines.
|
|
<VAR>dev</VAR> is the serial device, as for <CODE>target remote</CODE>;
|
|
<VAR>speed</VAR> allows you to specify the linespeed; and <VAR>PROG</VAR> is the
|
|
name of the program to be debugged, as it appears to DOS on the PC.
|
|
See section <A HREF="gdb.html#SEC118">The EBMON protocol for AMD29K</A>.
|
|
|
|
<A NAME="IDX468"></A>
|
|
<DT><CODE>target hms <VAR>dev</VAR></CODE>
|
|
<DD>
|
|
A Hitachi SH, H8/300, or H8/500 board, attached via serial line to your host.
|
|
Use special commands <CODE>device</CODE> and <CODE>speed</CODE> to control the serial
|
|
line and the communications speed used.
|
|
See section <A HREF="gdb.html#SEC132">GDB and Hitachi microprocessors</A>.
|
|
|
|
<A NAME="IDX469"></A>
|
|
<DT><CODE>target nindy <VAR>devicename</VAR></CODE>
|
|
<DD>
|
|
An Intel 960 board controlled by a Nindy Monitor. <VAR>devicename</VAR> is
|
|
the name of the serial device to use for the connection, e.g.
|
|
<TT>`/dev/ttya'</TT>. See section <A HREF="gdb.html#SEC113">GDB with a remote i960 (Nindy)</A>.
|
|
|
|
<A NAME="IDX470"></A>
|
|
<DT><CODE>target st2000 <VAR>dev</VAR> <VAR>speed</VAR></CODE>
|
|
<DD>
|
|
A Tandem ST2000 phone switch, running Tandem's STDBUG protocol. <VAR>dev</VAR>
|
|
is the name of the device attached to the ST2000 serial line;
|
|
<VAR>speed</VAR> is the communication line speed. The arguments are not used
|
|
if GDB is configured to connect to the ST2000 using TCP or Telnet.
|
|
See section <A HREF="gdb.html#SEC122">GDB with a Tandem ST2000</A>.
|
|
|
|
<A NAME="IDX471"></A>
|
|
<DT><CODE>target vxworks <VAR>machinename</VAR></CODE>
|
|
<DD>
|
|
A VxWorks system, attached via TCP/IP. The argument <VAR>machinename</VAR>
|
|
is the target system's machine name or IP address.
|
|
See section <A HREF="gdb.html#SEC123">GDB and VxWorks</A>.
|
|
|
|
<A NAME="IDX472"></A>
|
|
<DT><CODE>target bug <VAR>dev</VAR></CODE>
|
|
<DD>
|
|
BUG monitor, running on a MVME187 (m88k) board.
|
|
|
|
<A NAME="IDX473"></A>
|
|
<DT><CODE>target cpu32bug <VAR>dev</VAR></CODE>
|
|
<DD>
|
|
CPU32BUG monitor, running on a CPU32 (M68K) board.
|
|
|
|
<A NAME="IDX474"></A>
|
|
<DT><CODE>target op50n <VAR>dev</VAR></CODE>
|
|
<DD>
|
|
OP50N monitor, running on an OKI HPPA board.
|
|
|
|
<A NAME="IDX475"></A>
|
|
<DT><CODE>target w89k <VAR>dev</VAR></CODE>
|
|
<DD>
|
|
W89K monitor, running on a Winbond HPPA board.
|
|
|
|
<A NAME="IDX476"></A>
|
|
<DT><CODE>target est <VAR>dev</VAR></CODE>
|
|
<DD>
|
|
EST-300 ICE monitor, running on a CPU32 (M68K) board.
|
|
|
|
<A NAME="IDX477"></A>
|
|
<DT><CODE>target rom68k <VAR>dev</VAR></CODE>
|
|
<DD>
|
|
ROM 68K monitor, running on an IDP board.
|
|
|
|
<A NAME="IDX478"></A>
|
|
<DT><CODE>target array <VAR>dev</VAR></CODE>
|
|
<DD>
|
|
Array Tech LSI33K RAID controller board.
|
|
|
|
<A NAME="IDX479"></A>
|
|
<DT><CODE>target sparclite <VAR>dev</VAR></CODE>
|
|
<DD>
|
|
Fujitsu sparclite boards, used only for the purpose of loading.
|
|
You must use an additional command to debug the program.
|
|
For example: target remote <VAR>dev</VAR> using GDB standard
|
|
remote protocol.
|
|
</DL>
|
|
|
|
<P>
|
|
Different targets are available on different configurations of GDB;
|
|
your configuration may have more or fewer targets.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC104" HREF="gdb_toc.html#TOC104">Choosing target byte order</A></H2>
|
|
<P>
|
|
<A NAME="IDX480"></A>
|
|
<A NAME="IDX481"></A>
|
|
<A NAME="IDX482"></A>
|
|
<A NAME="IDX483"></A>
|
|
<A NAME="IDX484"></A>
|
|
<A NAME="IDX485"></A>
|
|
|
|
</P>
|
|
<P>
|
|
You can now choose which byte order to use with a target system.
|
|
Use the <CODE>set endian big</CODE> and <CODE>set endian little</CODE> commands.
|
|
Use the <CODE>set endian auto</CODE> command to instruct
|
|
GDB to use the byte order associated with the executable.
|
|
You can see the current setting for byte order with the <CODE>show endian</CODE>
|
|
command.
|
|
|
|
<EM>Warning:</EM> Currently, only embedded MIPS configurations support
|
|
dynamic selection of target byte order.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC105" HREF="gdb_toc.html#TOC105">Remote debugging</A></H2>
|
|
<P>
|
|
<A NAME="IDX486"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If you are trying to debug a program running on a machine that cannot run
|
|
GDB in the usual way, it is often useful to use remote debugging.
|
|
For example, you might use remote debugging on an operating system kernel,
|
|
or on a small system which does not have a general purpose operating system
|
|
powerful enough to run a full-featured debugger.
|
|
|
|
</P>
|
|
<P>
|
|
Some configurations of GDB have special serial or TCP/IP interfaces
|
|
to make this work with particular debugging targets. In addition,
|
|
GDB comes with a generic serial protocol (specific to GDB,
|
|
but not specific to any particular target system) which you can use if you
|
|
write the remote stubs--the code that runs on the remote system to
|
|
communicate with GDB.
|
|
|
|
</P>
|
|
<P>
|
|
Other remote targets may be available in your
|
|
configuration of GDB; use <CODE>help target</CODE> to list them.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC106" HREF="gdb_toc.html#TOC106">The GDB remote serial protocol</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX487"></A>
|
|
To debug a program running on another machine (the debugging
|
|
<STRONG>target</STRONG> machine), you must first arrange for all the usual
|
|
prerequisites for the program to run by itself. For example, for a C
|
|
program, you need:
|
|
|
|
</P>
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
A startup routine to set up the C runtime environment; these usually
|
|
have a name like <TT>`crt0'</TT>. The startup routine may be supplied by
|
|
your hardware supplier, or you may have to write your own.
|
|
|
|
<LI>
|
|
|
|
You probably need a C subroutine library to support your program's
|
|
subroutine calls, notably managing input and output.
|
|
|
|
<LI>
|
|
|
|
A way of getting your program to the other machine--for example, a
|
|
download program. These are often supplied by the hardware
|
|
manufacturer, but you may have to write your own from hardware
|
|
documentation.
|
|
</OL>
|
|
|
|
<P>
|
|
The next step is to arrange for your program to use a serial port to
|
|
communicate with the machine where GDB is running (the <STRONG>host</STRONG>
|
|
machine). In general terms, the scheme looks like this:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><EM>On the host,</EM>
|
|
<DD>
|
|
GDB already understands how to use this protocol; when everything
|
|
else is set up, you can simply use the <SAMP>`target remote'</SAMP> command
|
|
(see section <A HREF="gdb.html#SEC101">Specifying a Debugging Target</A>).
|
|
|
|
<DT><EM>On the target,</EM>
|
|
<DD>
|
|
you must link with your program a few special-purpose subroutines that
|
|
implement the GDB remote serial protocol. The file containing these
|
|
subroutines is called a <STRONG>debugging stub</STRONG>.
|
|
|
|
On certain remote targets, you can use an auxiliary program
|
|
<CODE>gdbserver</CODE> instead of linking a stub into your program.
|
|
See section <A HREF="gdb.html#SEC111">Using the <CODE>gdbserver</CODE> program</A>, for details.
|
|
</DL>
|
|
|
|
<P>
|
|
The debugging stub is specific to the architecture of the remote
|
|
machine; for example, use <TT>`sparc-stub.c'</TT> to debug programs on
|
|
SPARC boards.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX488"></A>
|
|
These working remote stubs are distributed with GDB:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>i386-stub.c</CODE>
|
|
<DD>
|
|
<A NAME="IDX489"></A>
|
|
<A NAME="IDX490"></A>
|
|
<A NAME="IDX491"></A>
|
|
For Intel 386 and compatible architectures.
|
|
|
|
<DT><CODE>m68k-stub.c</CODE>
|
|
<DD>
|
|
<A NAME="IDX492"></A>
|
|
<A NAME="IDX493"></A>
|
|
<A NAME="IDX494"></A>
|
|
For Motorola 680x0 architectures.
|
|
|
|
<DT><CODE>sh-stub.c</CODE>
|
|
<DD>
|
|
<A NAME="IDX495"></A>
|
|
<A NAME="IDX496"></A>
|
|
<A NAME="IDX497"></A>
|
|
For Hitachi SH architectures.
|
|
|
|
<DT><CODE>sparc-stub.c</CODE>
|
|
<DD>
|
|
<A NAME="IDX498"></A>
|
|
<A NAME="IDX499"></A>
|
|
For SPARC architectures.
|
|
|
|
<DT><CODE>sparcl-stub.c</CODE>
|
|
<DD>
|
|
<A NAME="IDX500"></A>
|
|
<A NAME="IDX501"></A>
|
|
<A NAME="IDX502"></A>
|
|
For Fujitsu SPARCLITE architectures.
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
The <TT>`README'</TT> file in the GDB distribution may list other
|
|
recently added stubs.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC107" HREF="gdb_toc.html#TOC107">What the stub can do for you</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX503"></A>
|
|
The debugging stub for your architecture supplies these three
|
|
subroutines:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set_debug_traps</CODE>
|
|
<DD>
|
|
<A NAME="IDX504"></A>
|
|
<A NAME="IDX505"></A>
|
|
This routine arranges for <CODE>handle_exception</CODE> to run when your
|
|
program stops. You must call this subroutine explicitly near the
|
|
beginning of your program.
|
|
|
|
<DT><CODE>handle_exception</CODE>
|
|
<DD>
|
|
<A NAME="IDX506"></A>
|
|
<A NAME="IDX507"></A>
|
|
This is the central workhorse, but your program never calls it
|
|
explicitly--the setup code arranges for <CODE>handle_exception</CODE> to
|
|
run when a trap is triggered.
|
|
|
|
<CODE>handle_exception</CODE> takes control when your program stops during
|
|
execution (for example, on a breakpoint), and mediates communications
|
|
with GDB on the host machine. This is where the communications
|
|
protocol is implemented; <CODE>handle_exception</CODE> acts as the GDB
|
|
representative on the target machine; it begins by sending summary
|
|
information on the state of your program, then continues to execute,
|
|
retrieving and transmitting any information GDB needs, until you
|
|
execute a GDB command that makes your program resume; at that point,
|
|
<CODE>handle_exception</CODE> returns control to your own code on the target
|
|
machine.
|
|
|
|
<DT><CODE>breakpoint</CODE>
|
|
<DD>
|
|
<A NAME="IDX508"></A>
|
|
Use this auxiliary subroutine to make your program contain a
|
|
breakpoint. Depending on the particular situation, this may be the only
|
|
way for GDB to get control. For instance, if your target
|
|
machine has some sort of interrupt button, you won't need to call this;
|
|
pressing the interrupt button transfers control to
|
|
<CODE>handle_exception</CODE>---in effect, to GDB. On some machines,
|
|
simply receiving characters on the serial port may also trigger a trap;
|
|
again, in that situation, you don't need to call <CODE>breakpoint</CODE> from
|
|
your own program--simply running <SAMP>`target remote'</SAMP> from the host
|
|
GDB session gets control.
|
|
|
|
Call <CODE>breakpoint</CODE> if none of these is true, or if you simply want
|
|
to make certain your program stops at a predetermined point for the
|
|
start of your debugging session.
|
|
</DL>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC108" HREF="gdb_toc.html#TOC108">What you must do for the stub</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX509"></A>
|
|
The debugging stubs that come with GDB are set up for a particular
|
|
chip architecture, but they have no information about the rest of your
|
|
debugging target machine.
|
|
|
|
</P>
|
|
<P>
|
|
First of all you need to tell the stub how to communicate with the
|
|
serial port.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>int getDebugChar()</CODE>
|
|
<DD>
|
|
<A NAME="IDX510"></A>
|
|
Write this subroutine to read a single character from the serial port.
|
|
It may be identical to <CODE>getchar</CODE> for your target system; a
|
|
different name is used to allow you to distinguish the two if you wish.
|
|
|
|
<DT><CODE>void putDebugChar(int)</CODE>
|
|
<DD>
|
|
<A NAME="IDX511"></A>
|
|
Write this subroutine to write a single character to the serial port.
|
|
It may be identical to <CODE>putchar</CODE> for your target system; a
|
|
different name is used to allow you to distinguish the two if you wish.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX512"></A>
|
|
<A NAME="IDX513"></A>
|
|
If you want GDB to be able to stop your program while it is
|
|
running, you need to use an interrupt-driven serial driver, and arrange
|
|
for it to stop when it receives a <CODE>^C</CODE> (<SAMP>`\003'</SAMP>, the control-C
|
|
character). That is the character which GDB uses to tell the
|
|
remote system to stop.
|
|
|
|
</P>
|
|
<P>
|
|
Getting the debugging target to return the proper status to GDB
|
|
probably requires changes to the standard stub; one quick and dirty way
|
|
is to just execute a breakpoint instruction (the "dirty" part is that
|
|
GDB reports a <CODE>SIGTRAP</CODE> instead of a <CODE>SIGINT</CODE>).
|
|
|
|
</P>
|
|
<P>
|
|
Other routines you need to supply are:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>void exceptionHandler (int <VAR>exception_number</VAR>, void *<VAR>exception_address</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX514"></A>
|
|
Write this function to install <VAR>exception_address</VAR> in the exception
|
|
handling tables. You need to do this because the stub does not have any
|
|
way of knowing what the exception handling tables on your target system
|
|
are like (for example, the processor's table might be in ROM,
|
|
containing entries which point to a table in RAM).
|
|
<VAR>exception_number</VAR> is the exception number which should be changed;
|
|
its meaning is architecture-dependent (for example, different numbers
|
|
might represent divide by zero, misaligned access, etc). When this
|
|
exception occurs, control should be transferred directly to
|
|
<VAR>exception_address</VAR>, and the processor state (stack, registers,
|
|
and so on) should be just as it is when a processor exception occurs. So if
|
|
you want to use a jump instruction to reach <VAR>exception_address</VAR>, it
|
|
should be a simple jump, not a jump to subroutine.
|
|
|
|
For the 386, <VAR>exception_address</VAR> should be installed as an interrupt
|
|
gate so that interrupts are masked while the handler runs. The gate
|
|
should be at privilege level 0 (the most privileged level). The
|
|
SPARC and 68k stubs are able to mask interrup themselves without
|
|
help from <CODE>exceptionHandler</CODE>.
|
|
|
|
<DT><CODE>void flush_i_cache()</CODE>
|
|
<DD>
|
|
<A NAME="IDX515"></A>
|
|
(sparc and sparclite only) Write this subroutine to flush the
|
|
instruction cache, if any, on your target machine. If there is no
|
|
instruction cache, this subroutine may be a no-op.
|
|
|
|
On target machines that have instruction caches, GDB requires this
|
|
function to make certain that the state of your program is stable.
|
|
</DL>
|
|
|
|
<P>
|
|
You must also make sure this library routine is available:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>void *memset(void *, int, int)</CODE>
|
|
<DD>
|
|
<A NAME="IDX516"></A>
|
|
This is the standard library function <CODE>memset</CODE> that sets an area of
|
|
memory to a known value. If you have one of the free versions of
|
|
<CODE>libc.a</CODE>, <CODE>memset</CODE> can be found there; otherwise, you must
|
|
either obtain it from your hardware manufacturer, or write your own.
|
|
</DL>
|
|
|
|
<P>
|
|
If you do not use the GNU C compiler, you may need other standard
|
|
library subroutines as well; this varies from one stub to another,
|
|
but in general the stubs are likely to use any of the common library
|
|
subroutines which <CODE>gcc</CODE> generates as inline code.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC109" HREF="gdb_toc.html#TOC109">Putting it all together</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX517"></A>
|
|
In summary, when your program is ready to debug, you must follow these
|
|
steps.
|
|
|
|
</P>
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
Make sure you have the supporting low-level routines
|
|
(see section <A HREF="gdb.html#SEC108">What you must do for the stub</A>):
|
|
|
|
<PRE>
|
|
<CODE>getDebugChar</CODE>, <CODE>putDebugChar</CODE>,
|
|
<CODE>flush_i_cache</CODE>, <CODE>memset</CODE>, <CODE>exceptionHandler</CODE>.
|
|
</PRE>
|
|
|
|
<LI>
|
|
|
|
Insert these lines near the top of your program:
|
|
|
|
|
|
<PRE>
|
|
set_debug_traps();
|
|
breakpoint();
|
|
</PRE>
|
|
|
|
<LI>
|
|
|
|
For the 680x0 stub only, you need to provide a variable called
|
|
<CODE>exceptionHook</CODE>. Normally you just use:
|
|
|
|
|
|
<PRE>
|
|
void (*exceptionHook)() = 0;
|
|
</PRE>
|
|
|
|
but if before calling <CODE>set_debug_traps</CODE>, you set it to point to a
|
|
function in your program, that function is called when
|
|
<CODE>GDB</CODE> continues after stopping on a trap (for example, bus
|
|
error). The function indicated by <CODE>exceptionHook</CODE> is called with
|
|
one parameter: an <CODE>int</CODE> which is the exception number.
|
|
|
|
<LI>
|
|
|
|
Compile and link together: your program, the GDB debugging stub for
|
|
your target architecture, and the supporting subroutines.
|
|
|
|
<LI>
|
|
|
|
Make sure you have a serial connection between your target machine and
|
|
the GDB host, and identify the serial port on the host.
|
|
|
|
<LI>
|
|
|
|
Download your program to your target machine (or get it there by
|
|
whatever means the manufacturer provides), and start it.
|
|
|
|
<LI>
|
|
|
|
To start remote debugging, run GDB on the host machine, and specify
|
|
as an executable file the program that is running in the remote machine.
|
|
This tells GDB how to find your program's symbols and the contents
|
|
of its pure text.
|
|
|
|
<A NAME="IDX518"></A>
|
|
Then establish communication using the <CODE>target remote</CODE> command.
|
|
Its argument specifies how to communicate with the target
|
|
machine--either via a devicename attached to a direct serial line, or a
|
|
TCP port (usually to a terminal server which in turn has a serial line
|
|
to the target). For example, to use a serial line connected to the
|
|
device named <TT>`/dev/ttyb'</TT>:
|
|
|
|
|
|
<PRE>
|
|
target remote /dev/ttyb
|
|
</PRE>
|
|
|
|
<A NAME="IDX519"></A>
|
|
To use a TCP connection, use an argument of the form
|
|
<CODE><VAR>host</VAR>:port</CODE>. For example, to connect to port 2828 on a
|
|
terminal server named <CODE>manyfarms</CODE>:
|
|
|
|
|
|
<PRE>
|
|
target remote manyfarms:2828
|
|
</PRE>
|
|
|
|
</OL>
|
|
|
|
<P>
|
|
Now you can use all the usual commands to examine and change data and to
|
|
step and continue the remote program.
|
|
|
|
</P>
|
|
<P>
|
|
To resume the remote program and stop debugging it, use the <CODE>detach</CODE>
|
|
command.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX520"></A>
|
|
<A NAME="IDX521"></A>
|
|
Whenever GDB is waiting for the remote program, if you type the
|
|
interrupt character (often <KBD>C-C</KBD>), GDB attempts to stop the
|
|
program. This may or may not succeed, depending in part on the hardware
|
|
and the serial drivers the remote system uses. If you type the
|
|
interrupt character once again, GDB displays this prompt:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
Interrupted while waiting for the program.
|
|
Give up (and stop debugging it)? (y or n)
|
|
</PRE>
|
|
|
|
<P>
|
|
If you type <KBD>y</KBD>, GDB abandons the remote debugging session.
|
|
(If you decide you want to try again later, you can use <SAMP>`target
|
|
remote'</SAMP> again to connect once more.) If you type <KBD>n</KBD>, GDB
|
|
goes back to waiting.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC110" HREF="gdb_toc.html#TOC110">Communication protocol</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX522"></A>
|
|
<A NAME="IDX523"></A>
|
|
<A NAME="IDX524"></A>
|
|
The stub files provided with GDB implement the target side of the
|
|
communication protocol, and the GDB side is implemented in the
|
|
GDB source file <TT>`remote.c'</TT>. Normally, you can simply allow
|
|
these subroutines to communicate, and ignore the details. (If you're
|
|
implementing your own stub file, you can still ignore the details: start
|
|
with one of the existing stub files. <TT>`sparc-stub.c'</TT> is the best
|
|
organized, and therefore the easiest to read.)
|
|
|
|
</P>
|
|
<P>
|
|
However, there may be occasions when you need to know something about
|
|
the protocol--for example, if there is only one serial port to your
|
|
target machine, you might want your program to do something special if
|
|
it recognizes a packet meant for GDB.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX525"></A>
|
|
<A NAME="IDX526"></A>
|
|
<A NAME="IDX527"></A>
|
|
All GDB commands and responses (other than acknowledgements, which
|
|
are single characters) are sent as a packet which includes a
|
|
checksum. A packet is introduced with the character <SAMP>`$'</SAMP>, and ends
|
|
with the character <SAMP>`#'</SAMP> followed by a two-digit checksum:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$<VAR>packet info</VAR>#<VAR>checksum</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX528"></A>
|
|
<VAR>checksum</VAR> is computed as the modulo 256 sum of the <VAR>packet
|
|
info</VAR> characters.
|
|
|
|
</P>
|
|
<P>
|
|
When either the host or the target machine receives a packet, the first
|
|
response expected is an acknowledgement: a single character, either
|
|
<SAMP>`+'</SAMP> (to indicate the package was received correctly) or <SAMP>`-'</SAMP>
|
|
(to request retransmission).
|
|
|
|
</P>
|
|
<P>
|
|
The host (GDB) sends commands, and the target (the debugging stub
|
|
incorporated in your program) sends data in response. The target also
|
|
sends data when your program stops.
|
|
|
|
</P>
|
|
<P>
|
|
Command packets are distinguished by their first character, which
|
|
identifies the kind of command.
|
|
|
|
</P>
|
|
<P>
|
|
These are some of the commands currently supported (for a complete list of
|
|
commands, look in <TT>`gdb/remote.c.'</TT>):
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>g</CODE>
|
|
<DD>
|
|
Requests the values of CPU registers.
|
|
|
|
<DT><CODE>G</CODE>
|
|
<DD>
|
|
Sets the values of CPU registers.
|
|
|
|
<DT><CODE>m<VAR>addr</VAR>,<VAR>count</VAR></CODE>
|
|
<DD>
|
|
Read <VAR>count</VAR> bytes at location <VAR>addr</VAR>.
|
|
|
|
<DT><CODE>M<VAR>addr</VAR>,<VAR>count</VAR>:...</CODE>
|
|
<DD>
|
|
Write <VAR>count</VAR> bytes at location <VAR>addr</VAR>.
|
|
|
|
<DT><CODE>c</CODE>
|
|
<DD>
|
|
<DT><CODE>c<VAR>addr</VAR></CODE>
|
|
<DD>
|
|
Resume execution at the current address (or at <VAR>addr</VAR> if supplied).
|
|
|
|
<DT><CODE>s</CODE>
|
|
<DD>
|
|
<DT><CODE>s<VAR>addr</VAR></CODE>
|
|
<DD>
|
|
Step the target program for one instruction, from either the current
|
|
program counter or from <VAR>addr</VAR> if supplied.
|
|
|
|
<DT><CODE>k</CODE>
|
|
<DD>
|
|
Kill the target program.
|
|
|
|
<DT><CODE>?</CODE>
|
|
<DD>
|
|
Report the most recent signal. To allow you to take advantage of the
|
|
GDB signal handling commands, one of the functions of the debugging
|
|
stub is to report CPU traps as the corresponding POSIX signal values.
|
|
|
|
<DT><CODE>T</CODE>
|
|
<DD>
|
|
Allows the remote stub to send only the registers that GDB needs
|
|
to make a quick decision about single-stepping or conditional breakpoints.
|
|
This eliminates the need to fetch the entire register set for each instruction
|
|
being stepped through.
|
|
|
|
The GDB remote serial protocol now implements a write-through
|
|
cache for registers. GDB only re-reads the registers if the
|
|
target has run.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX529"></A>
|
|
<A NAME="IDX530"></A>
|
|
<A NAME="IDX531"></A>
|
|
<A NAME="IDX532"></A>
|
|
If you have trouble with the serial connection, you can use the command
|
|
<CODE>set remotedebug</CODE>. This makes GDB report on all packets sent
|
|
back and forth across the serial line to the remote machine. The
|
|
packet-debugging information is printed on the GDB standard output
|
|
stream. <CODE>set remotedebug off</CODE> turns it off, and <CODE>show
|
|
remotedebug</CODE> shows you its current state.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC111" HREF="gdb_toc.html#TOC111">Using the <CODE>gdbserver</CODE> program</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX533"></A>
|
|
<A NAME="IDX534"></A>
|
|
<CODE>gdbserver</CODE> is a control program for Unix-like systems, which
|
|
allows you to connect your program with a remote GDB via
|
|
<CODE>target remote</CODE>---but without linking in the usual debugging stub.
|
|
|
|
</P>
|
|
<P>
|
|
<CODE>gdbserver</CODE> is not a complete replacement for the debugging stubs,
|
|
because it requires essentially the same operating-system facilities
|
|
that GDB itself does. In fact, a system that can run
|
|
<CODE>gdbserver</CODE> to connect to a remote GDB could also run
|
|
GDB locally! <CODE>gdbserver</CODE> is sometimes useful nevertheless,
|
|
because it is a much smaller program than GDB itself. It is
|
|
also easier to port than all of GDB, so you may be able to get
|
|
started more quickly on a new system by using <CODE>gdbserver</CODE>.
|
|
Finally, if you develop code for real-time systems, you may find that
|
|
the tradeoffs involved in real-time operation make it more convenient to
|
|
do as much development work as possible on another system, for example
|
|
by cross-compiling. You can use <CODE>gdbserver</CODE> to make a similar
|
|
choice for debugging.
|
|
|
|
</P>
|
|
<P>
|
|
GDB and <CODE>gdbserver</CODE> communicate via either a serial line
|
|
or a TCP connection, using the standard GDB remote serial
|
|
protocol.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><EM>On the target machine,</EM>
|
|
<DD>
|
|
you need to have a copy of the program you want to debug.
|
|
<CODE>gdbserver</CODE> does not need your program's symbol table, so you can
|
|
strip the program if necessary to save space. GDB on the host
|
|
system does all the symbol handling.
|
|
|
|
To use the server, you must tell it how to communicate with GDB;
|
|
the name of your program; and the arguments for your program. The
|
|
syntax is:
|
|
|
|
|
|
<PRE>
|
|
target> gdbserver <VAR>comm</VAR> <VAR>program</VAR> [ <VAR>args</VAR> ... ]
|
|
</PRE>
|
|
|
|
<VAR>comm</VAR> is either a device name (to use a serial line) or a TCP
|
|
hostname and portnumber. For example, to debug Emacs with the argument
|
|
<SAMP>`foo.txt'</SAMP> and communicate with GDB over the serial port
|
|
<TT>`/dev/com1'</TT>:
|
|
|
|
|
|
<PRE>
|
|
target> gdbserver /dev/com1 emacs foo.txt
|
|
</PRE>
|
|
|
|
<CODE>gdbserver</CODE> waits passively for the host GDB to communicate
|
|
with it.
|
|
|
|
To use a TCP connection instead of a serial line:
|
|
|
|
|
|
<PRE>
|
|
target> gdbserver host:2345 emacs foo.txt
|
|
</PRE>
|
|
|
|
The only difference from the previous example is the first argument,
|
|
specifying that you are communicating with the host GDB via
|
|
TCP. The <SAMP>`host:2345'</SAMP> argument means that <CODE>gdbserver</CODE> is to
|
|
expect a TCP connection from machine <SAMP>`host'</SAMP> to local TCP port 2345.
|
|
(Currently, the <SAMP>`host'</SAMP> part is ignored.) You can choose any number
|
|
you want for the port number as long as it does not conflict with any
|
|
TCP ports already in use on the target system (for example, <CODE>23</CODE> is
|
|
reserved for <CODE>telnet</CODE>).<A NAME="DOCF3" HREF="gdb_foot.html#FOOT3">(3)</A> You must use the same port number with the host GDB
|
|
<CODE>target remote</CODE> command.
|
|
|
|
<DT><EM>On the GDB host machine,</EM>
|
|
<DD>
|
|
you need an unstripped copy of your program, since GDB needs
|
|
symbols and debugging information. Start up GDB as usual,
|
|
using the name of the local copy of your program as the first argument.
|
|
(You may also need the <SAMP>`--baud'</SAMP> option if the serial line is
|
|
running at anything other than 9600 bps.) After that, use <CODE>target
|
|
remote</CODE> to establish communications with <CODE>gdbserver</CODE>. Its argument
|
|
is either a device name (usually a serial device, like
|
|
<TT>`/dev/ttyb'</TT>), or a TCP port descriptor in the form
|
|
<CODE><VAR>host</VAR>:<VAR>PORT</VAR></CODE>. For example:
|
|
|
|
|
|
<PRE>
|
|
(gdb) target remote /dev/ttyb
|
|
</PRE>
|
|
|
|
communicates with the server via serial line <TT>`/dev/ttyb'</TT>, and
|
|
|
|
|
|
<PRE>
|
|
(gdb) target remote the-target:2345
|
|
</PRE>
|
|
|
|
communicates via a TCP connection to port 2345 on host <TT>`the-target'</TT>.
|
|
For TCP connections, you must start up <CODE>gdbserver</CODE> prior to using
|
|
the <CODE>target remote</CODE> command. Otherwise you may get an error whose
|
|
text depends on the host system, but which usually looks something like
|
|
<SAMP>`Connection refused'</SAMP>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC112" HREF="gdb_toc.html#TOC112">Using the <CODE>gdbserve.nlm</CODE> program</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX535"></A>
|
|
<CODE>gdbserve.nlm</CODE> is a control program for NetWare systems, which
|
|
allows you to connect your program with a remote GDB via
|
|
<CODE>target remote</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
GDB and <CODE>gdbserve.nlm</CODE> communicate via a serial line,
|
|
using the standard GDB remote serial protocol.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><EM>On the target machine,</EM>
|
|
<DD>
|
|
you need to have a copy of the program you want to debug.
|
|
<CODE>gdbserve.nlm</CODE> does not need your program's symbol table, so you
|
|
can strip the program if necessary to save space. GDB on the
|
|
host system does all the symbol handling.
|
|
|
|
To use the server, you must tell it how to communicate with
|
|
GDB; the name of your program; and the arguments for your
|
|
program. The syntax is:
|
|
|
|
|
|
<PRE>
|
|
load gdbserve [ BOARD=<VAR>board</VAR> ] [ PORT=<VAR>port</VAR> ]
|
|
[ BAUD=<VAR>baud</VAR> ] <VAR>program</VAR> [ <VAR>args</VAR> ... ]
|
|
</PRE>
|
|
|
|
<VAR>board</VAR> and <VAR>port</VAR> specify the serial line; <VAR>baud</VAR> specifies
|
|
the baud rate used by the connection. <VAR>port</VAR> and <VAR>node</VAR> default
|
|
to 0, <VAR>baud</VAR> defaults to 9600 bps.
|
|
|
|
For example, to debug Emacs with the argument <SAMP>`foo.txt'</SAMP>and
|
|
communicate with GDB over serial port number 2 or board 1
|
|
using a 19200 bps connection:
|
|
|
|
|
|
<PRE>
|
|
load gdbserve BOARD=1 PORT=2 BAUD=19200 emacs foo.txt
|
|
</PRE>
|
|
|
|
<DT><EM>On the GDB host machine,</EM>
|
|
<DD>
|
|
you need an unstripped copy of your program, since GDB needs
|
|
symbols and debugging information. Start up GDB as usual,
|
|
using the name of the local copy of your program as the first argument.
|
|
(You may also need the <SAMP>`--baud'</SAMP> option if the serial line is
|
|
running at anything other than 9600 bps. After that, use <CODE>target
|
|
remote</CODE> to establish communications with <CODE>gdbserve.nlm</CODE>. Its
|
|
argument is a device name (usually a serial device, like
|
|
<TT>`/dev/ttyb'</TT>). For example:
|
|
|
|
|
|
<PRE>
|
|
(gdb) target remote /dev/ttyb
|
|
</PRE>
|
|
|
|
communications with the server via serial line <TT>`/dev/ttyb'</TT>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC113" HREF="gdb_toc.html#TOC113">GDB with a remote i960 (Nindy)</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX536"></A>
|
|
<A NAME="IDX537"></A>
|
|
<STRONG>Nindy</STRONG> is a ROM Monitor program for Intel 960 target systems. When
|
|
GDB is configured to control a remote Intel 960 using Nindy, you can
|
|
tell GDB how to connect to the 960 in several ways:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Through command line options specifying serial port, version of the
|
|
Nindy protocol, and communications speed;
|
|
|
|
<LI>
|
|
|
|
By responding to a prompt on startup;
|
|
|
|
<LI>
|
|
|
|
By using the <CODE>target</CODE> command at any point during your GDB
|
|
session. See section <A HREF="gdb.html#SEC103">Commands for managing targets</A>.
|
|
|
|
</UL>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC114" HREF="gdb_toc.html#TOC114">Startup with Nindy</A></H4>
|
|
|
|
<P>
|
|
If you simply start <CODE>gdb</CODE> without using any command-line
|
|
options, you are prompted for what serial port to use, <EM>before</EM> you
|
|
reach the ordinary GDB prompt:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
Attach /dev/ttyNN -- specify NN, or "quit" to quit:
|
|
</PRE>
|
|
|
|
<P>
|
|
Respond to the prompt with whatever suffix (after <SAMP>`/dev/tty'</SAMP>)
|
|
identifies the serial port you want to use. You can, if you choose,
|
|
simply start up with no Nindy connection by responding to the prompt
|
|
with an empty line. If you do this and later wish to attach to Nindy,
|
|
use <CODE>target</CODE> (see section <A HREF="gdb.html#SEC103">Commands for managing targets</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC115" HREF="gdb_toc.html#TOC115">Options for Nindy</A></H4>
|
|
|
|
<P>
|
|
These are the startup options for beginning your GDB session with a
|
|
Nindy-960 board attached:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>-r <VAR>port</VAR></CODE>
|
|
<DD>
|
|
Specify the serial port name of a serial interface to be used to connect
|
|
to the target system. This option is only available when GDB is
|
|
configured for the Intel 960 target architecture. You may specify
|
|
<VAR>port</VAR> as any of: a full pathname (e.g. <SAMP>`-r /dev/ttya'</SAMP>), a
|
|
device name in <TT>`/dev'</TT> (e.g. <SAMP>`-r ttya'</SAMP>), or simply the unique
|
|
suffix for a specific <CODE>tty</CODE> (e.g. <SAMP>`-r a'</SAMP>).
|
|
|
|
<DT><CODE>-O</CODE>
|
|
<DD>
|
|
(An uppercase letter "O", not a zero.) Specify that GDB should use
|
|
the "old" Nindy monitor protocol to connect to the target system.
|
|
This option is only available when GDB is configured for the Intel 960
|
|
target architecture.
|
|
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> if you specify <SAMP>`-O'</SAMP>, but are actually trying to
|
|
connect to a target system that expects the newer protocol, the connection
|
|
fails, appearing to be a speed mismatch. GDB repeatedly
|
|
attempts to reconnect at several different line speeds. You can abort
|
|
this process with an interrupt.
|
|
</BLOCKQUOTE>
|
|
|
|
<DT><CODE>-brk</CODE>
|
|
<DD>
|
|
Specify that GDB should first send a <CODE>BREAK</CODE> signal to the target
|
|
system, in an attempt to reset it, before connecting to a Nindy target.
|
|
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> Many target systems do not have the hardware that this
|
|
requires; it only works with a few boards.
|
|
</BLOCKQUOTE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
The standard <SAMP>`-b'</SAMP> option controls the line speed used on the serial
|
|
port.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC116" HREF="gdb_toc.html#TOC116">Nindy reset command</A></H4>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>reset</CODE>
|
|
<DD>
|
|
<A NAME="IDX538"></A>
|
|
For a Nindy target, this command sends a "break" to the remote target
|
|
system; this is only useful if the target has been equipped with a
|
|
circuit to perform a hard reset (or some other interesting action) when
|
|
a break is detected.
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC117" HREF="gdb_toc.html#TOC117">The UDI protocol for AMD29K</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX539"></A>
|
|
<A NAME="IDX540"></A>
|
|
GDB supports AMD's UDI ("Universal Debugger Interface")
|
|
protocol for debugging the a29k processor family. To use this
|
|
configuration with AMD targets running the MiniMON monitor, you need the
|
|
program <CODE>MONTIP</CODE>, available from AMD at no charge. You can also
|
|
use GDB with the UDI-conformant a29k simulator program
|
|
<CODE>ISSTIP</CODE>, also available from AMD.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>target udi <VAR>keyword</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX541"></A>
|
|
Select the UDI interface to a remote a29k board or simulator, where
|
|
<VAR>keyword</VAR> is an entry in the AMD configuration file <TT>`udi_soc'</TT>.
|
|
This file contains keyword entries which specify parameters used to
|
|
connect to a29k targets. If the <TT>`udi_soc'</TT> file is not in your
|
|
working directory, you must set the environment variable <SAMP>`UDICONF'</SAMP>
|
|
to its pathname.
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC118" HREF="gdb_toc.html#TOC118">The EBMON protocol for AMD29K</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX542"></A>
|
|
<A NAME="IDX543"></A>
|
|
|
|
</P>
|
|
<P>
|
|
AMD distributes a 29K development board meant to fit in a PC, together
|
|
with a DOS-hosted monitor program called <CODE>EBMON</CODE>. As a shorthand
|
|
term, this development system is called the "EB29K". To use
|
|
GDB from a Unix system to run programs on the EB29K board, you
|
|
must first connect a serial cable between the PC (which hosts the EB29K
|
|
board) and a serial port on the Unix system. In the following, we
|
|
assume you've hooked the cable between the PC's <TT>`COM1'</TT> port and
|
|
<TT>`/dev/ttya'</TT> on the Unix system.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC119" HREF="gdb_toc.html#TOC119">Communications setup</A></H4>
|
|
|
|
<P>
|
|
The next step is to set up the PC's port, by doing something like this
|
|
in DOS on the PC:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
C:\> MODE com1:9600,n,8,1,none
|
|
</PRE>
|
|
|
|
<P>
|
|
This example--run on an MS DOS 4.0 system--sets the PC port to 9600
|
|
bps, no parity, eight data bits, one stop bit, and no "retry" action;
|
|
you must match the communications parameters when establishing the Unix
|
|
end of the connection as well.
|
|
|
|
</P>
|
|
<P>
|
|
To give control of the PC to the Unix side of the serial line, type
|
|
the following at the DOS console:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
C:\> CTTY com1
|
|
</PRE>
|
|
|
|
<P>
|
|
(Later, if you wish to return control to the DOS console, you can use
|
|
the command <CODE>CTTY con</CODE>---but you must send it over the device that
|
|
had control, in our example over the <TT>`COM1'</TT> serial line).
|
|
|
|
</P>
|
|
<P>
|
|
From the Unix host, use a communications program such as <CODE>tip</CODE> or
|
|
<CODE>cu</CODE> to communicate with the PC; for example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
cu -s 9600 -l /dev/ttya
|
|
</PRE>
|
|
|
|
<P>
|
|
The <CODE>cu</CODE> options shown specify, respectively, the linespeed and the
|
|
serial port to use. If you use <CODE>tip</CODE> instead, your command line
|
|
may look something like the following:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
tip -9600 /dev/ttya
|
|
</PRE>
|
|
|
|
<P>
|
|
Your system may require a different name where we show
|
|
<TT>`/dev/ttya'</TT> as the argument to <CODE>tip</CODE>. The communications
|
|
parameters, including which port to use, are associated with the
|
|
<CODE>tip</CODE> argument in the "remote" descriptions file--normally the
|
|
system table <TT>`/etc/remote'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX544"></A>
|
|
Using the <CODE>tip</CODE> or <CODE>cu</CODE> connection, change the DOS working
|
|
directory to the directory containing a copy of your 29K program, then
|
|
start the PC program <CODE>EBMON</CODE> (an EB29K control program supplied
|
|
with your board by AMD). You should see an initial display from
|
|
<CODE>EBMON</CODE> similar to the one that follows, ending with the
|
|
<CODE>EBMON</CODE> prompt <SAMP>`#'</SAMP>---
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
C:\> G:
|
|
|
|
G:\> CD \usr\joe\work29k
|
|
|
|
G:\USR\JOE\WORK29K> EBMON
|
|
Am29000 PC Coprocessor Board Monitor, version 3.0-18
|
|
Copyright 1990 Advanced Micro Devices, Inc.
|
|
Written by Gibbons and Associates, Inc.
|
|
|
|
Enter '?' or 'H' for help
|
|
|
|
PC Coprocessor Type = EB29K
|
|
I/O Base = 0x208
|
|
Memory Base = 0xd0000
|
|
|
|
Data Memory Size = 2048KB
|
|
Available I-RAM Range = 0x8000 to 0x1fffff
|
|
Available D-RAM Range = 0x80002000 to 0x801fffff
|
|
|
|
PageSize = 0x400
|
|
Register Stack Size = 0x800
|
|
Memory Stack Size = 0x1800
|
|
|
|
CPU PRL = 0x3
|
|
Am29027 Available = No
|
|
Byte Write Available = Yes
|
|
|
|
# ~.
|
|
</PRE>
|
|
|
|
<P>
|
|
Then exit the <CODE>cu</CODE> or <CODE>tip</CODE> program (done in the example by
|
|
typing <CODE>~.</CODE> at the <CODE>EBMON</CODE> prompt). <CODE>EBMON</CODE> keeps
|
|
running, ready for GDB to take over.
|
|
|
|
</P>
|
|
<P>
|
|
For this example, we've assumed what is probably the most convenient
|
|
way to make sure the same 29K program is on both the PC and the Unix
|
|
system: a PC/NFS connection that establishes "drive <CODE>G:</CODE>" on the
|
|
PC as a file system on the Unix host. If you do not have PC/NFS or
|
|
something similar connecting the two systems, you must arrange some
|
|
other way--perhaps floppy-disk transfer--of getting the 29K program
|
|
from the Unix system to the PC; GDB does <EM>not</EM> download it over the
|
|
serial line.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC120" HREF="gdb_toc.html#TOC120">EB29K cross-debugging</A></H4>
|
|
|
|
<P>
|
|
Finally, <CODE>cd</CODE> to the directory containing an image of your 29K
|
|
program on the Unix system, and start GDB---specifying as argument the
|
|
name of your 29K program:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
cd /usr/joe/work29k
|
|
gdb myfoo
|
|
</PRE>
|
|
|
|
<P>
|
|
Now you can use the <CODE>target</CODE> command:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
target amd-eb /dev/ttya 9600 MYFOO
|
|
</PRE>
|
|
|
|
<P>
|
|
In this example, we've assumed your program is in a file called
|
|
<TT>`myfoo'</TT>. Note that the filename given as the last argument to
|
|
<CODE>target amd-eb</CODE> should be the name of the program as it appears to DOS.
|
|
In our example this is simply <CODE>MYFOO</CODE>, but in general it can include
|
|
a DOS path, and depending on your transfer mechanism may not resemble
|
|
the name on the Unix side.
|
|
|
|
</P>
|
|
<P>
|
|
At this point, you can set any breakpoints you wish; when you are ready
|
|
to see your program run on the 29K board, use the GDB command
|
|
<CODE>run</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
To stop debugging the remote program, use the GDB <CODE>detach</CODE>
|
|
command.
|
|
|
|
</P>
|
|
<P>
|
|
To return control of the PC to its console, use <CODE>tip</CODE> or <CODE>cu</CODE>
|
|
once again, after your GDB session has concluded, to attach to
|
|
<CODE>EBMON</CODE>. You can then type the command <CODE>q</CODE> to shut down
|
|
<CODE>EBMON</CODE>, returning control to the DOS command-line interpreter.
|
|
Type <CODE>CTTY con</CODE> to return command input to the main DOS console,
|
|
and type <KBD>~.</KBD> to leave <CODE>tip</CODE> or <CODE>cu</CODE>.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC121" HREF="gdb_toc.html#TOC121">Remote log</A></H4>
|
|
<P>
|
|
<A NAME="IDX545"></A>
|
|
<A NAME="IDX546"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>target amd-eb</CODE> command creates a file <TT>`eb.log'</TT> in the
|
|
current working directory, to help debug problems with the connection.
|
|
<TT>`eb.log'</TT> records all the output from <CODE>EBMON</CODE>, including echoes
|
|
of the commands sent to it. Running <SAMP>`tail -f'</SAMP> on this file in
|
|
another window often helps to understand trouble with <CODE>EBMON</CODE>, or
|
|
unexpected events on the PC side of the connection.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC122" HREF="gdb_toc.html#TOC122">GDB with a Tandem ST2000</A></H3>
|
|
|
|
<P>
|
|
To connect your ST2000 to the host system, see the manufacturer's
|
|
manual. Once the ST2000 is physically attached, you can run:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
target st2000 <VAR>dev</VAR> <VAR>speed</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
to establish it as your debugging environment. <VAR>dev</VAR> is normally
|
|
the name of a serial device, such as <TT>`/dev/ttya'</TT>, connected to the
|
|
ST2000 via a serial line. You can instead specify <VAR>dev</VAR> as a TCP
|
|
connection (for example, to a serial line attached via a terminal
|
|
concentrator) using the syntax <CODE><VAR>hostname</VAR>:<VAR>portnumber</VAR></CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>load</CODE> and <CODE>attach</CODE> commands are <EM>not</EM> defined for
|
|
this target; you must load your program into the ST2000 as you normally
|
|
would for standalone operation. GDB reads debugging information
|
|
(such as symbols) from a separate, debugging version of the program
|
|
available on your host computer.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX547"></A>
|
|
These auxiliary GDB commands are available to help you with the ST2000
|
|
environment:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>st2000 <VAR>command</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX548"></A>
|
|
<A NAME="IDX549"></A>
|
|
<A NAME="IDX550"></A>
|
|
Send a <VAR>command</VAR> to the STDBUG monitor. See the manufacturer's
|
|
manual for available commands.
|
|
|
|
<DT><CODE>connect</CODE>
|
|
<DD>
|
|
<A NAME="IDX551"></A>
|
|
Connect the controlling terminal to the STDBUG command monitor. When
|
|
you are done interacting with STDBUG, typing either of two character
|
|
sequences gets you back to the GDB command prompt:
|
|
<KBD><KBD>RET</KBD>~.</KBD> (Return, followed by tilde and period) or
|
|
<KBD><KBD>RET</KBD>~<KBD>C-d</KBD></KBD> (Return, followed by tilde and control-D).
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC123" HREF="gdb_toc.html#TOC123">GDB and VxWorks</A></H3>
|
|
<P>
|
|
<A NAME="IDX552"></A>
|
|
|
|
</P>
|
|
<P>
|
|
GDB enables developers to spawn and debug tasks running on networked
|
|
VxWorks targets from a Unix host. Already-running tasks spawned from
|
|
the VxWorks shell can also be debugged. GDB uses code that runs on
|
|
both the Unix host and on the VxWorks target. The program
|
|
<CODE>gdb</CODE> is installed and executed on the Unix host. (It may be
|
|
installed with the name <CODE>vxgdb</CODE>, to distinguish it from a
|
|
GDB for debugging programs on the host itself.)
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>VxWorks-timeout <VAR>args</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX553"></A>
|
|
All VxWorks-based targets now support the option <CODE>vxworks-timeout</CODE>.
|
|
This option is set by the user, and <VAR>args</VAR> represents the number of
|
|
seconds GDB waits for responses to rpc's. You might use this if
|
|
your VxWorks target is a slow software simulator or is on the far side
|
|
of a thin network line.
|
|
</DL>
|
|
|
|
<P>
|
|
The following information on connecting to VxWorks was current when
|
|
this manual was produced; newer releases of VxWorks may use revised
|
|
procedures.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX554"></A>
|
|
To use GDB with VxWorks, you must rebuild your VxWorks kernel
|
|
to include the remote debugging interface routines in the VxWorks
|
|
library <TT>`rdb.a'</TT>. To do this, define <CODE>INCLUDE_RDB</CODE> in the
|
|
VxWorks configuration file <TT>`configAll.h'</TT> and rebuild your VxWorks
|
|
kernel. The resulting kernel contains <TT>`rdb.a'</TT>, and spawns the
|
|
source debugging task <CODE>tRdbTask</CODE> when VxWorks is booted. For more
|
|
information on configuring and remaking VxWorks, see the manufacturer's
|
|
manual.
|
|
|
|
</P>
|
|
<P>
|
|
Once you have included <TT>`rdb.a'</TT> in your VxWorks system image and set
|
|
your Unix execution search path to find GDB, you are ready to
|
|
run GDB. From your Unix host, run <CODE>gdb</CODE> (or <CODE>vxgdb</CODE>,
|
|
depending on your installation).
|
|
|
|
</P>
|
|
<P>
|
|
GDB comes up showing the prompt:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(vxgdb)
|
|
</PRE>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC124" HREF="gdb_toc.html#TOC124">Connecting to VxWorks</A></H4>
|
|
|
|
<P>
|
|
The GDB command <CODE>target</CODE> lets you connect to a VxWorks target on the
|
|
network. To connect to a target whose host name is "<CODE>tt</CODE>", type:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(vxgdb) target vxworks tt
|
|
</PRE>
|
|
|
|
<P>
|
|
GDB displays messages like these:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
Attaching remote machine across net...
|
|
Connected to tt.
|
|
</PRE>
|
|
|
|
<P>
|
|
GDB then attempts to read the symbol tables of any object modules
|
|
loaded into the VxWorks target since it was last booted. GDB locates
|
|
these files by searching the directories listed in the command search
|
|
path (see section <A HREF="gdb.html#SEC19">Your program's environment</A>); if it fails
|
|
to find an object file, it displays a message such as:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
prog.o: No such file or directory.
|
|
</PRE>
|
|
|
|
<P>
|
|
When this happens, add the appropriate directory to the search path with
|
|
the GDB command <CODE>path</CODE>, and execute the <CODE>target</CODE>
|
|
command again.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC125" HREF="gdb_toc.html#TOC125">VxWorks download</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX555"></A>
|
|
If you have connected to the VxWorks target and you want to debug an
|
|
object that has not yet been loaded, you can use the GDB
|
|
<CODE>load</CODE> command to download a file from Unix to VxWorks
|
|
incrementally. The object file given as an argument to the <CODE>load</CODE>
|
|
command is actually opened twice: first by the VxWorks target in order
|
|
to download the code, then by GDB in order to read the symbol
|
|
table. This can lead to problems if the current working directories on
|
|
the two systems differ. If both systems have NFS mounted the same
|
|
filesystems, you can avoid these problems by using absolute paths.
|
|
Otherwise, it is simplest to set the working directory on both systems
|
|
to the directory in which the object file resides, and then to reference
|
|
the file by its name, without any path. For instance, a program
|
|
<TT>`prog.o'</TT> may reside in <TT>`<VAR>vxpath</VAR>/vw/demo/rdb'</TT> in VxWorks
|
|
and in <TT>`<VAR>hostpath</VAR>/vw/demo/rdb'</TT> on the host. To load this
|
|
program, type this on VxWorks:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
-> cd "<VAR>vxpath</VAR>/vw/demo/rdb"
|
|
</PRE>
|
|
|
|
<P>
|
|
v
|
|
Then, in GDB, type:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(vxgdb) cd <VAR>hostpath</VAR>/vw/demo/rdb
|
|
(vxgdb) load prog.o
|
|
</PRE>
|
|
|
|
<P>
|
|
GDB displays a response similar to this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
Reading symbol data from wherever/vw/demo/rdb/prog.o... done.
|
|
</PRE>
|
|
|
|
<P>
|
|
You can also use the <CODE>load</CODE> command to reload an object module
|
|
after editing and recompiling the corresponding source file. Note that
|
|
this makes GDB delete all currently-defined breakpoints,
|
|
auto-displays, and convenience variables, and to clear the value
|
|
history. (This is necessary in order to preserve the integrity of
|
|
debugger data structures that reference the target system's symbol
|
|
table.)
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC126" HREF="gdb_toc.html#TOC126">Running tasks</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX556"></A>
|
|
You can also attach to an existing task using the <CODE>attach</CODE> command as
|
|
follows:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(vxgdb) attach <VAR>task</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
where <VAR>task</VAR> is the VxWorks hexadecimal task ID. The task can be running
|
|
or suspended when you attach to it. Running tasks are suspended at
|
|
the time of attachment.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC127" HREF="gdb_toc.html#TOC127">GDB and Sparclet</A></H3>
|
|
<P>
|
|
<A NAME="IDX557"></A>
|
|
|
|
</P>
|
|
<P>
|
|
GDB enables developers to debug tasks running on
|
|
Sparclet targets from a Unix host.
|
|
GDB uses code that runs on
|
|
both the Unix host and on the Sparclet target. The program
|
|
<CODE>gdb</CODE> is installed and executed on the Unix host.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>timeout <VAR>args</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX558"></A>
|
|
GDB now supports the option <CODE>remotetimeout</CODE>.
|
|
This option is set by the user, and <VAR>args</VAR> represents the number of
|
|
seconds GDB waits for responses.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX559"></A>
|
|
When compiling for debugging, include the options "-g" to get debug
|
|
information and "-Ttext" to relocate the program to where you wish to
|
|
load it on the target. You may also want to add the options "-n" or
|
|
"-N" in order to reduce the size of the sections.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
sparclet-aout-gcc prog.c -Ttext 0x12010000 -g -o prog -N
|
|
</PRE>
|
|
|
|
<P>
|
|
You can use objdump to verify that the addresses are what you intended.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
sparclet-aout-objdump --headers --syms prog
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX560"></A>
|
|
Once you have set
|
|
your Unix execution search path to find GDB, you are ready to
|
|
run GDB. From your Unix host, run <CODE>gdb</CODE>
|
|
(or <CODE>sparclet-aout-gdb</CODE>, depending on your installation).
|
|
|
|
</P>
|
|
<P>
|
|
GDB comes up showing the prompt:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdbslet)
|
|
</PRE>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC128" HREF="gdb_toc.html#TOC128">Setting file to debug</A></H4>
|
|
|
|
<P>
|
|
The GDB command <CODE>file</CODE> lets you choose with program to debug.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdbslet) file prog
|
|
</PRE>
|
|
|
|
<P>
|
|
GDB then attempts to read the symbol table of <TT>`prog'</TT>.
|
|
GDB locates
|
|
the file by searching the directories listed in the command search
|
|
path.
|
|
If the file was compiled with debug information (option "-g"), source
|
|
files will be searched as well.
|
|
GDB locates
|
|
the source files by searching the directories listed in the directory search
|
|
path (see section <A HREF="gdb.html#SEC19">Your program's environment</A>).
|
|
If it fails
|
|
to find a file, it displays a message such as:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
prog: No such file or directory.
|
|
</PRE>
|
|
|
|
<P>
|
|
When this happens, add the appropriate directories to the search paths with
|
|
the GDB commands <CODE>path</CODE> and <CODE>dir</CODE>, and execute the
|
|
<CODE>target</CODE> command again.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC129" HREF="gdb_toc.html#TOC129">Connecting to Sparclet</A></H4>
|
|
|
|
<P>
|
|
The GDB command <CODE>target</CODE> lets you connect to a Sparclet target.
|
|
To connect to a target on serial port "<CODE>ttya</CODE>", type:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdbslet) target sparclet /dev/ttya
|
|
Remote target sparclet connected to /dev/ttya
|
|
main () at ../prog.c:3
|
|
</PRE>
|
|
|
|
<P>
|
|
GDB displays messages like these:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
Connected to ttya.
|
|
</PRE>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC130" HREF="gdb_toc.html#TOC130">Sparclet download</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX561"></A>
|
|
Once connected to the Sparclet target,
|
|
you can use the GDB
|
|
<CODE>load</CODE> command to download the file from the host to the target.
|
|
The file name and load offset should be given as arguments to the <CODE>load</CODE>
|
|
command.
|
|
Since the file format is aout, the program must be loaded to the starting
|
|
address. You can use objdump to find out what this value is. The load
|
|
offset is an offset which is added to the VMA (virtual memory address)
|
|
of each of the file's sections.
|
|
For instance, if the program
|
|
<TT>`prog'</TT> was linked to text address 0x1201000, with data at 0x12010160
|
|
and bss at 0x12010170, in GDB, type:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdbslet) load prog 0x12010000
|
|
Loading section .text, size 0xdb0 vma 0x12010000
|
|
</PRE>
|
|
|
|
<P>
|
|
If the code is loaded at a different address then what the program was linked
|
|
to, you may need to use the <CODE>section</CODE> and <CODE>add-symbol-file</CODE> commands
|
|
to tell GDB where to map the symbol table.
|
|
|
|
</P>
|
|
|
|
|
|
<H4><A NAME="SEC131" HREF="gdb_toc.html#TOC131">Running and debugging</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX562"></A>
|
|
You can now begin debugging the task using GDB's execution control
|
|
commands, <CODE>b</CODE>, <CODE>step</CODE>, <CODE>run</CODE>, etc. See the GDB
|
|
manual for the list of commands.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdbslet) b main
|
|
Breakpoint 1 at 0x12010000: file prog.c, line 3.
|
|
(gdbslet) run
|
|
Starting program: prog
|
|
Breakpoint 1, main (argc=1, argv=0xeffff21c) at prog.c:3
|
|
3 char *symarg = 0;
|
|
(gdbslet) step
|
|
4 char *execarg = "hello!";
|
|
(gdbslet)
|
|
</PRE>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC132" HREF="gdb_toc.html#TOC132">GDB and Hitachi microprocessors</A></H3>
|
|
<P>
|
|
GDB needs to know these things to talk to your
|
|
Hitachi SH, H8/300, or H8/500:
|
|
|
|
</P>
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
that you want to use <SAMP>`target hms'</SAMP>, the remote debugging interface
|
|
for Hitachi microprocessors, or <SAMP>`target e7000'</SAMP>, the in-circuit
|
|
emulator for the Hitachi SH and the Hitachi 300H. (<SAMP>`target hms'</SAMP> is
|
|
the default when GDB is configured specifically for the Hitachi SH,
|
|
H8/300, or H8/500.)
|
|
|
|
<LI>
|
|
|
|
what serial device connects your host to your Hitachi board (the first
|
|
serial device available on your host is the default).
|
|
|
|
<LI>
|
|
|
|
what speed to use over the serial device.
|
|
</OL>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC133" HREF="gdb_toc.html#TOC133">Connecting to Hitachi boards</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX563"></A>
|
|
<A NAME="IDX564"></A>
|
|
Use the special <CODE>gdb</CODE> command <SAMP>`device <VAR>port</VAR>'</SAMP> if you
|
|
need to explicitly set the serial device. The default <VAR>port</VAR> is the
|
|
first available port on your host. This is only necessary on Unix
|
|
hosts, where it is typically something like <TT>`/dev/ttya'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX565"></A>
|
|
<A NAME="IDX566"></A>
|
|
<CODE>gdb</CODE> has another special command to set the communications
|
|
speed: <SAMP>`speed <VAR>bps</VAR>'</SAMP>. This command also is only used from Unix
|
|
hosts; on DOS hosts, set the line speed as usual from outside GDB with
|
|
the DOS <KBD>mode</KBD> command (for instance, <SAMP>`mode
|
|
com2:9600,n,8,1,p'</SAMP> for a 9600 bps connection).
|
|
|
|
</P>
|
|
<P>
|
|
The <SAMP>`device'</SAMP> and <SAMP>`speed'</SAMP> commands are available only when you
|
|
use a Unix host to debug your Hitachi microprocessor programs. If you
|
|
use a DOS host,
|
|
GDB depends on an auxiliary terminate-and-stay-resident program
|
|
called <CODE>asynctsr</CODE> to communicate with the development board
|
|
through a PC serial port. You must also use the DOS <CODE>mode</CODE> command
|
|
to set up the serial port on the DOS side.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC134" HREF="gdb_toc.html#TOC134">Using the E7000 in-circuit emulator</A></H4>
|
|
|
|
<P>
|
|
<A NAME="IDX567"></A>
|
|
You can use the E7000 in-circuit emulator to develop code for either the
|
|
Hitachi SH or the H8/300H. Use one of these forms of the <SAMP>`target
|
|
e7000'</SAMP> command to connect GDB to your E7000:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>target e7000 <VAR>port</VAR> <VAR>speed</VAR></CODE>
|
|
<DD>
|
|
Use this form if your E7000 is connected to a serial port. The
|
|
<VAR>port</VAR> argument identifies what serial port to use (for example,
|
|
<SAMP>`com2'</SAMP>). The third argument is the line speed in bits per second
|
|
(for example, <SAMP>`9600'</SAMP>).
|
|
|
|
<DT><CODE>target e7000 <VAR>hostname</VAR></CODE>
|
|
<DD>
|
|
If your E7000 is installed as a host on a TCP/IP network, you can just
|
|
specify its hostname; GDB uses <CODE>telnet</CODE> to connect.
|
|
</DL>
|
|
|
|
|
|
|
|
<H4><A NAME="SEC135" HREF="gdb_toc.html#TOC135">Special GDB commands for Hitachi micros</A></H4>
|
|
|
|
<P>
|
|
Some GDB commands are available only on the H8/300 or the
|
|
H8/500 configurations:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set machine h8300</CODE>
|
|
<DD>
|
|
<A NAME="IDX568"></A>
|
|
<A NAME="IDX569"></A>
|
|
|
|
<DT><CODE>set machine h8300h</CODE>
|
|
<DD>
|
|
Condition GDB for one of the two variants of the H8/300
|
|
architecture with <SAMP>`set machine'</SAMP>. You can use <SAMP>`show machine'</SAMP>
|
|
to check which variant is currently in effect.
|
|
|
|
<A NAME="IDX570"></A>
|
|
<A NAME="IDX571"></A>
|
|
<DT><CODE>set memory <VAR>mod</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>show memory</CODE>
|
|
<DD>
|
|
Specify which H8/500 memory model (<VAR>mod</VAR>) you are using with
|
|
<SAMP>`set memory'</SAMP>; check which memory model is in effect with <SAMP>`show
|
|
memory'</SAMP>. The accepted values for <VAR>mod</VAR> are <CODE>small</CODE>,
|
|
<CODE>big</CODE>, <CODE>medium</CODE>, and <CODE>compact</CODE>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC136" HREF="gdb_toc.html#TOC136">GDB and remote MIPS boards</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX572"></A>
|
|
GDB can use the MIPS remote debugging protocol to talk to a
|
|
MIPS board attached to a serial line. This is available when
|
|
you configure GDB with <SAMP>`--target=mips-idt-ecoff'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
Use these GDB commands to specify the connection to your target board:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>target mips <VAR>port</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX573"></A>
|
|
To run a program on the board, start up <CODE>gdb</CODE> with the
|
|
name of your program as the argument. To connect to the board, use the
|
|
command <SAMP>`target mips <VAR>port</VAR>'</SAMP>, where <VAR>port</VAR> is the name of
|
|
the serial port connected to the board. If the program has not already
|
|
been downloaded to the board, you may use the <CODE>load</CODE> command to
|
|
download it. You can then use all the usual GDB commands.
|
|
|
|
For example, this sequence connects to the target board through a serial
|
|
port, and loads and runs a program called <VAR>prog</VAR> through the
|
|
debugger:
|
|
|
|
|
|
<PRE>
|
|
host$ gdb <VAR>prog</VAR>
|
|
GDB is free software and ...
|
|
(gdb) target mips /dev/ttyb
|
|
(gdb) load <VAR>prog</VAR>
|
|
(gdb) run
|
|
</PRE>
|
|
|
|
<DT><CODE>target mips <VAR>hostname</VAR>:<VAR>portnumber</VAR></CODE>
|
|
<DD>
|
|
On some GDB host configurations, you can specify a TCP
|
|
connection (for instance, to a serial line managed by a terminal
|
|
concentrator) instead of a serial port, using the syntax
|
|
<SAMP>`<VAR>hostname</VAR>:<VAR>portnumber</VAR>'</SAMP>.
|
|
|
|
<DT><CODE>target pmon <VAR>port</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX574"></A>
|
|
|
|
<DT><CODE>target ddb <VAR>port</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX575"></A>
|
|
|
|
<DT><CODE>target lsi <VAR>port</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX576"></A>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
GDB also supports these special commands for MIPS targets:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set processor <VAR>args</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>show processor</CODE>
|
|
<DD>
|
|
<A NAME="IDX577"></A>
|
|
<A NAME="IDX578"></A>
|
|
Use the <CODE>set processor</CODE> command to set the type of MIPS
|
|
processor when you want to access processor-type-specific registers.
|
|
For example, <CODE>set processor <VAR>r3041</VAR></CODE> tells GDB
|
|
to use the CPO registers appropriate for the 3041 chip.
|
|
Use the <CODE>show processor</CODE> command to see what MIPS processor GDB
|
|
is using. Use the <CODE>info reg</CODE> command to see what registers
|
|
GDB is using.
|
|
|
|
<DT><CODE>set mipsfpu double</CODE>
|
|
<DD>
|
|
<DT><CODE>set mipsfpu single</CODE>
|
|
<DD>
|
|
<DT><CODE>set mipsfpu none</CODE>
|
|
<DD>
|
|
<DT><CODE>show mipsfpu</CODE>
|
|
<DD>
|
|
<A NAME="IDX579"></A>
|
|
<A NAME="IDX580"></A>
|
|
<A NAME="IDX581"></A>
|
|
<A NAME="IDX582"></A>
|
|
If your target board does not support the MIPS floating point
|
|
coprocessor, you should use the command <SAMP>`set mipsfpu none'</SAMP> (if you
|
|
need this, you may wish to put the command in your .gdbinit
|
|
file). This tells GDB how to find the return value of
|
|
functions which return floating point values. It also allows
|
|
GDB to avoid saving the floating point registers when calling
|
|
functions on the board. If you are using a floating point coprocessor
|
|
with only single precision floating point support, as on the R4650
|
|
processor, use the command <SAMP>`set mipsfpu single'</SAMP>. The default
|
|
double precision floating point coprocessor may be selected using
|
|
<SAMP>`set mipsfpu double'</SAMP>.
|
|
|
|
In previous versions the only choices were double precision or no
|
|
floating point, so <SAMP>`set mipsfpu on'</SAMP> will select double precision
|
|
and <SAMP>`set mipsfpu off'</SAMP> will select no floating point.
|
|
|
|
As usual, you can inquire about the <CODE>mipsfpu</CODE> variable with
|
|
<SAMP>`show mipsfpu'</SAMP>.
|
|
|
|
<DT><CODE>set remotedebug <VAR>n</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>show remotedebug</CODE>
|
|
<DD>
|
|
<A NAME="IDX583"></A>
|
|
<A NAME="IDX584"></A>
|
|
<A NAME="IDX585"></A>
|
|
<A NAME="IDX586"></A>
|
|
You can see some debugging information about communications with the board
|
|
by setting the <CODE>remotedebug</CODE> variable. If you set it to <CODE>1</CODE> using
|
|
<SAMP>`set remotedebug 1'</SAMP>, every packet is displayed. If you set it
|
|
to <CODE>2</CODE>, every character is displayed. You can check the current value
|
|
at any time with the command <SAMP>`show remotedebug'</SAMP>.
|
|
|
|
<DT><CODE>set timeout <VAR>seconds</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>set retransmit-timeout <VAR>seconds</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>show timeout</CODE>
|
|
<DD>
|
|
<DT><CODE>show retransmit-timeout</CODE>
|
|
<DD>
|
|
<A NAME="IDX587"></A>
|
|
<A NAME="IDX588"></A>
|
|
<A NAME="IDX589"></A>
|
|
<A NAME="IDX590"></A>
|
|
<A NAME="IDX591"></A>
|
|
<A NAME="IDX592"></A>
|
|
You can control the timeout used while waiting for a packet, in the MIPS
|
|
remote protocol, with the <CODE>set timeout <VAR>seconds</VAR></CODE> command. The
|
|
default is 5 seconds. Similarly, you can control the timeout used while
|
|
waiting for an acknowledgement of a packet with the <CODE>set
|
|
retransmit-timeout <VAR>seconds</VAR></CODE> command. The default is 3 seconds.
|
|
You can inspect both values with <CODE>show timeout</CODE> and <CODE>show
|
|
retransmit-timeout</CODE>. (These commands are <EM>only</EM> available when
|
|
GDB is configured for <SAMP>`--target=mips-idt-ecoff'</SAMP>.)
|
|
|
|
The timeout set by <CODE>set timeout</CODE> does not apply when GDB
|
|
is waiting for your program to stop. In that case, GDB waits
|
|
forever because it has no way of knowing how long the program is going
|
|
to run before stopping.
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC137" HREF="gdb_toc.html#TOC137">Simulated CPU target</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX593"></A>
|
|
<A NAME="IDX594"></A>
|
|
<A NAME="IDX595"></A>
|
|
<A NAME="IDX596"></A>
|
|
<A NAME="IDX597"></A>
|
|
<A NAME="IDX598"></A>
|
|
<A NAME="IDX599"></A>
|
|
<A NAME="IDX600"></A>
|
|
For some configurations, GDB includes a CPU simulator that you
|
|
can use instead of a hardware CPU to debug your programs. Currently,
|
|
a simulator is available when GDB is configured to debug Zilog
|
|
Z8000 or Hitachi microprocessor targets.
|
|
|
|
</P>
|
|
|
|
<P>
|
|
For the Z8000 family, <SAMP>`target sim'</SAMP> simulates either the Z8002 (the
|
|
unsegmented variant of the Z8000 architecture) or the Z8001 (the
|
|
segmented variant). The simulator recognizes which architecture is
|
|
appropriate by inspecting the object code.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>target sim</CODE>
|
|
<DD>
|
|
<A NAME="IDX601"></A>
|
|
<A NAME="IDX602"></A>
|
|
Debug programs on a simulated CPU
|
|
(which CPU depends on the GDB configuration)
|
|
</DL>
|
|
|
|
<P>
|
|
After specifying this target, you can debug programs for the simulated
|
|
CPU in the same style as programs for your host computer; use the
|
|
<CODE>file</CODE> command to load a new program image, the <CODE>run</CODE> command
|
|
to run your program, and so on.
|
|
|
|
</P>
|
|
<P>
|
|
As well as making available all the usual machine registers (see
|
|
<CODE>info reg</CODE>), this debugging target provides three additional items
|
|
of information as specially named registers:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>cycles</CODE>
|
|
<DD>
|
|
Counts clock-ticks in the simulator.
|
|
|
|
<DT><CODE>insts</CODE>
|
|
<DD>
|
|
Counts instructions run in the simulator.
|
|
|
|
<DT><CODE>time</CODE>
|
|
<DD>
|
|
Execution time in 60ths of a second.
|
|
</DL>
|
|
|
|
<P>
|
|
You can refer to these values in GDB expressions with the usual
|
|
conventions; for example, <SAMP>`b fputc if $cycles>5000'</SAMP> sets a
|
|
conditional breakpoint that suspends only after at least 5000
|
|
simulated clock ticks.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC138" HREF="gdb_toc.html#TOC138">Controlling GDB</A></H1>
|
|
|
|
<P>
|
|
You can alter the way GDB interacts with you by using
|
|
the <CODE>set</CODE> command. For commands controlling how GDB displays
|
|
data, see section <A HREF="gdb.html#SEC58">Print settings</A>; other settings are described
|
|
here.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC139" HREF="gdb_toc.html#TOC139">Prompt</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX603"></A>
|
|
|
|
</P>
|
|
<P>
|
|
GDB indicates its readiness to read a command by printing a string
|
|
called the <STRONG>prompt</STRONG>. This string is normally <SAMP>`(gdb)'</SAMP>. You
|
|
can change the prompt string with the <CODE>set prompt</CODE> command. For
|
|
instance, when debugging GDB with GDB, it is useful to change
|
|
the prompt in one of the GDB sessions so that you can always tell
|
|
which one you are talking to.
|
|
|
|
</P>
|
|
<P>
|
|
<EM>Note:</EM> <CODE>set prompt</CODE> no longer adds a space for you after the
|
|
prompt you set. This allows you to set a prompt which ends in a space
|
|
or a prompt that does not.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set prompt <VAR>newprompt</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX604"></A>
|
|
|
|
Directs GDB to use <VAR>newprompt</VAR> as its prompt string henceforth.
|
|
|
|
<A NAME="IDX605"></A>
|
|
<DT><CODE>show prompt</CODE>
|
|
<DD>
|
|
Prints a line of the form: <SAMP>`Gdb's prompt is: <VAR>your-prompt</VAR>'</SAMP>
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC140" HREF="gdb_toc.html#TOC140">Command editing</A></H2>
|
|
<P>
|
|
<A NAME="IDX606"></A>
|
|
<A NAME="IDX607"></A>
|
|
|
|
</P>
|
|
<P>
|
|
GDB reads its input commands via the <STRONG>readline</STRONG> interface. This
|
|
GNU library provides consistent behavior for programs which provide a
|
|
command line interface to the user. Advantages are GNU Emacs-style
|
|
or <STRONG>vi</STRONG>-style inline editing of commands, <CODE>csh</CODE>-like history
|
|
substitution, and a storage and recall of command history across
|
|
debugging sessions.
|
|
|
|
</P>
|
|
<P>
|
|
You may control the behavior of command line editing in GDB with the
|
|
command <CODE>set</CODE>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set editing</CODE>
|
|
<DD>
|
|
<A NAME="IDX608"></A>
|
|
<A NAME="IDX609"></A>
|
|
|
|
<DT><CODE>set editing on</CODE>
|
|
<DD>
|
|
Enable command line editing (enabled by default).
|
|
|
|
<DT><CODE>set editing off</CODE>
|
|
<DD>
|
|
Disable command line editing.
|
|
|
|
<A NAME="IDX610"></A>
|
|
<DT><CODE>show editing</CODE>
|
|
<DD>
|
|
Show whether command line editing is enabled.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC141" HREF="gdb_toc.html#TOC141">Command history</A></H2>
|
|
|
|
<P>
|
|
GDB can keep track of the commands you type during your
|
|
debugging sessions, so that you can be certain of precisely what
|
|
happened. Use these commands to manage the GDB command
|
|
history facility.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set history filename <VAR>fname</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX611"></A>
|
|
<A NAME="IDX612"></A>
|
|
<A NAME="IDX613"></A>
|
|
<A NAME="IDX614"></A>
|
|
|
|
Set the name of the GDB command history file to <VAR>fname</VAR>.
|
|
This is the file where GDB reads an initial command history
|
|
list, and where it writes the command history from this session when it
|
|
exits. You can access this list through history expansion or through
|
|
the history command editing characters listed below. This file defaults
|
|
to the value of the environment variable <CODE>GDBHISTFILE</CODE>, or to
|
|
<TT>`./.gdb_history'</TT> if this variable is not set.
|
|
|
|
<A NAME="IDX615"></A>
|
|
<A NAME="IDX616"></A>
|
|
<DT><CODE>set history save</CODE>
|
|
<DD>
|
|
<DT><CODE>set history save on</CODE>
|
|
<DD>
|
|
Record command history in a file, whose name may be specified with the
|
|
<CODE>set history filename</CODE> command. By default, this option is disabled.
|
|
|
|
<DT><CODE>set history save off</CODE>
|
|
<DD>
|
|
Stop recording command history in a file.
|
|
|
|
<A NAME="IDX617"></A>
|
|
<A NAME="IDX618"></A>
|
|
<DT><CODE>set history size <VAR>size</VAR></CODE>
|
|
<DD>
|
|
Set the number of commands which GDB keeps in its history list.
|
|
This defaults to the value of the environment variable
|
|
<CODE>HISTSIZE</CODE>, or to 256 if this variable is not set.
|
|
</DL>
|
|
|
|
<P>
|
|
<A NAME="IDX619"></A>
|
|
History expansion assigns special meaning to the character <KBD>!</KBD>.
|
|
|
|
</P>
|
|
<P>
|
|
Since <KBD>!</KBD> is also the logical not operator in C, history expansion
|
|
is off by default. If you decide to enable history expansion with the
|
|
<CODE>set history expansion on</CODE> command, you may sometimes need to
|
|
follow <KBD>!</KBD> (when it is used as logical not, in an expression) with
|
|
a space or a tab to prevent it from being expanded. The readline
|
|
history facilities do not attempt substitution on the strings
|
|
<KBD>!=</KBD> and <KBD>!(</KBD>, even when history expansion is enabled.
|
|
|
|
</P>
|
|
<P>
|
|
The commands to control history expansion are:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set history expansion on</CODE>
|
|
<DD>
|
|
<A NAME="IDX620"></A>
|
|
|
|
<DT><CODE>set history expansion</CODE>
|
|
<DD>
|
|
Enable history expansion. History expansion is off by default.
|
|
|
|
<DT><CODE>set history expansion off</CODE>
|
|
<DD>
|
|
Disable history expansion.
|
|
|
|
The readline code comes with more complete documentation of
|
|
editing and history expansion features. Users unfamiliar with GNU Emacs
|
|
or <CODE>vi</CODE> may wish to read it.
|
|
|
|
<A NAME="IDX621"></A>
|
|
<DT><CODE>show history</CODE>
|
|
<DD>
|
|
<DT><CODE>show history filename</CODE>
|
|
<DD>
|
|
<DT><CODE>show history save</CODE>
|
|
<DD>
|
|
<DT><CODE>show history size</CODE>
|
|
<DD>
|
|
<DT><CODE>show history expansion</CODE>
|
|
<DD>
|
|
These commands display the state of the GDB history parameters.
|
|
<CODE>show history</CODE> by itself displays all four states.
|
|
</DL>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>show commands</CODE>
|
|
<DD>
|
|
<A NAME="IDX622"></A>
|
|
|
|
Display the last ten commands in the command history.
|
|
|
|
<DT><CODE>show commands <VAR>n</VAR></CODE>
|
|
<DD>
|
|
Print ten commands centered on command number <VAR>n</VAR>.
|
|
|
|
<DT><CODE>show commands +</CODE>
|
|
<DD>
|
|
Print ten commands just after the commands last printed.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC142" HREF="gdb_toc.html#TOC142">Screen size</A></H2>
|
|
<P>
|
|
<A NAME="IDX623"></A>
|
|
<A NAME="IDX624"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Certain commands to GDB may produce large amounts of
|
|
information output to the screen. To help you read all of it,
|
|
GDB pauses and asks you for input at the end of each page of
|
|
output. Type <KBD>RET</KBD> when you want to continue the output, or <KBD>q</KBD>
|
|
to discard the remaining output. Also, the screen width setting
|
|
determines when to wrap lines of output. Depending on what is being
|
|
printed, GDB tries to break the line at a readable place,
|
|
rather than simply letting it overflow onto the following line.
|
|
|
|
</P>
|
|
<P>
|
|
Normally GDB knows the size of the screen from the termcap data base
|
|
together with the value of the <CODE>TERM</CODE> environment variable and the
|
|
<CODE>stty rows</CODE> and <CODE>stty cols</CODE> settings. If this is not correct,
|
|
you can override it with the <CODE>set height</CODE> and <CODE>set
|
|
width</CODE> commands:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set height <VAR>lpp</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX625"></A>
|
|
<A NAME="IDX626"></A>
|
|
<A NAME="IDX627"></A>
|
|
<A NAME="IDX628"></A>
|
|
|
|
<DT><CODE>show height</CODE>
|
|
<DD>
|
|
<DT><CODE>set width <VAR>cpl</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>show width</CODE>
|
|
<DD>
|
|
These <CODE>set</CODE> commands specify a screen height of <VAR>lpp</VAR> lines and
|
|
a screen width of <VAR>cpl</VAR> characters. The associated <CODE>show</CODE>
|
|
commands display the current settings.
|
|
|
|
If you specify a height of zero lines, GDB does not pause during
|
|
output no matter how long the output is. This is useful if output is to a
|
|
file or to an editor buffer.
|
|
|
|
Likewise, you can specify <SAMP>`set width 0'</SAMP> to prevent GDB
|
|
from wrapping its output.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC143" HREF="gdb_toc.html#TOC143">Numbers</A></H2>
|
|
<P>
|
|
<A NAME="IDX629"></A>
|
|
<A NAME="IDX630"></A>
|
|
|
|
</P>
|
|
<P>
|
|
You can always enter numbers in octal, decimal, or hexadecimal in GDB by
|
|
the usual conventions: octal numbers begin with <SAMP>`0'</SAMP>, decimal
|
|
numbers end with <SAMP>`.'</SAMP>, and hexadecimal numbers begin with <SAMP>`0x'</SAMP>.
|
|
Numbers that begin with none of these are, by default, entered in base
|
|
10; likewise, the default display for numbers--when no particular
|
|
format is specified--is base 10. You can change the default base for
|
|
both input and output with the <CODE>set radix</CODE> command.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set input-radix <VAR>base</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX631"></A>
|
|
|
|
Set the default base for numeric input. Supported choices
|
|
for <VAR>base</VAR> are decimal 8, 10, or 16. <VAR>base</VAR> must itself be
|
|
specified either unambiguously or using the current default radix; for
|
|
example, any of
|
|
|
|
|
|
<PRE>
|
|
set radix 012
|
|
set radix 10.
|
|
set radix 0xa
|
|
</PRE>
|
|
|
|
sets the base to decimal. On the other hand, <SAMP>`set radix 10'</SAMP>
|
|
leaves the radix unchanged no matter what it was.
|
|
|
|
<A NAME="IDX632"></A>
|
|
<DT><CODE>set output-radix <VAR>base</VAR></CODE>
|
|
<DD>
|
|
Set the default base for numeric display. Supported choices
|
|
for <VAR>base</VAR> are decimal 8, 10, or 16. <VAR>base</VAR> must itself be
|
|
specified either unambiguously or using the current default radix.
|
|
|
|
<A NAME="IDX633"></A>
|
|
<DT><CODE>show input-radix</CODE>
|
|
<DD>
|
|
Display the current default base for numeric input.
|
|
|
|
<A NAME="IDX634"></A>
|
|
<DT><CODE>show output-radix</CODE>
|
|
<DD>
|
|
Display the current default base for numeric display.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC144" HREF="gdb_toc.html#TOC144">Optional warnings and messages</A></H2>
|
|
|
|
<P>
|
|
By default, GDB is silent about its inner workings. If you are running
|
|
on a slow machine, you may want to use the <CODE>set verbose</CODE> command.
|
|
This makes GDB tell you when it does a lengthy internal operation, so
|
|
you will not think it has crashed.
|
|
|
|
</P>
|
|
<P>
|
|
Currently, the messages controlled by <CODE>set verbose</CODE> are those
|
|
which announce that the symbol table for a source file is being read;
|
|
see <CODE>symbol-file</CODE> in section <A HREF="gdb.html#SEC99">Commands to specify files</A>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set verbose on</CODE>
|
|
<DD>
|
|
<A NAME="IDX635"></A>
|
|
|
|
Enables GDB output of certain informational messages.
|
|
|
|
<DT><CODE>set verbose off</CODE>
|
|
<DD>
|
|
Disables GDB output of certain informational messages.
|
|
|
|
<A NAME="IDX636"></A>
|
|
<DT><CODE>show verbose</CODE>
|
|
<DD>
|
|
Displays whether <CODE>set verbose</CODE> is on or off.
|
|
</DL>
|
|
|
|
<P>
|
|
By default, if GDB encounters bugs in the symbol table of an object
|
|
file, it is silent; but if you are debugging a compiler, you may find
|
|
this information useful (see section <A HREF="gdb.html#SEC100">Errors reading symbol files</A>).
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set complaints <VAR>limit</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX637"></A>
|
|
|
|
Permits GDB to output <VAR>limit</VAR> complaints about each type of unusual
|
|
symbols before becoming silent about the problem. Set <VAR>limit</VAR> to
|
|
zero to suppress all complaints; set it to a large number to prevent
|
|
complaints from being suppressed.
|
|
|
|
<A NAME="IDX638"></A>
|
|
<DT><CODE>show complaints</CODE>
|
|
<DD>
|
|
Displays how many symbol complaints GDB is permitted to produce.
|
|
</DL>
|
|
|
|
<P>
|
|
By default, GDB is cautious, and asks what sometimes seems to be a
|
|
lot of stupid questions to confirm certain commands. For example, if
|
|
you try to run a program which is already running:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(gdb) run
|
|
The program being debugged has been started already.
|
|
Start it from the beginning? (y or n)
|
|
</PRE>
|
|
|
|
<P>
|
|
If you are willing to unflinchingly face the consequences of your own
|
|
commands, you can disable this "feature":
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>set confirm off</CODE>
|
|
<DD>
|
|
<A NAME="IDX639"></A>
|
|
<A NAME="IDX640"></A>
|
|
<A NAME="IDX641"></A>
|
|
<A NAME="IDX642"></A>
|
|
|
|
Disables confirmation requests.
|
|
|
|
<DT><CODE>set confirm on</CODE>
|
|
<DD>
|
|
Enables confirmation requests (the default).
|
|
|
|
<A NAME="IDX643"></A>
|
|
<DT><CODE>show confirm</CODE>
|
|
<DD>
|
|
Displays state of confirmation requests.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC145" HREF="gdb_toc.html#TOC145">Canned Sequences of Commands</A></H1>
|
|
|
|
<P>
|
|
Aside from breakpoint commands (see section <A HREF="gdb.html#SEC35">Breakpoint command lists</A>), GDB provides two ways to store sequences of commands
|
|
for execution as a unit: user-defined commands and command files.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC146" HREF="gdb_toc.html#TOC146">User-defined commands</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX644"></A>
|
|
A <STRONG>user-defined command</STRONG> is a sequence of GDB commands to which
|
|
you assign a new name as a command. This is done with the <CODE>define</CODE>
|
|
command. User commands may accept up to 10 arguments separated by whitespace.
|
|
Arguments are accessed within the user command via <VAR>$arg0...$arg9</VAR>.
|
|
A trivial example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
define adder
|
|
print $arg0 + $arg1 + $arg2
|
|
</PRE>
|
|
|
|
<P>
|
|
To execute the command use:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
adder 1 2 3
|
|
</PRE>
|
|
|
|
<P>
|
|
This defines the command <CODE>adder</CODE>, which prints the sum of
|
|
its three arguments. Note the arguments are text substitutions, so they may
|
|
reference variables, use complex expressions, or even perform inferior
|
|
functions calls.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>define <VAR>commandname</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX645"></A>
|
|
|
|
Define a command named <VAR>commandname</VAR>. If there is already a command
|
|
by that name, you are asked to confirm that you want to redefine it.
|
|
|
|
The definition of the command is made up of other GDB command lines,
|
|
which are given following the <CODE>define</CODE> command. The end of these
|
|
commands is marked by a line containing <CODE>end</CODE>.
|
|
|
|
<A NAME="IDX646"></A>
|
|
<A NAME="IDX647"></A>
|
|
<DT><CODE>if</CODE>
|
|
<DD>
|
|
Takes a single argument, which is an expression to evaluate.
|
|
It is followed by a series of commands that are executed
|
|
only if the expression is true (nonzero).
|
|
There can then optionally be a line <CODE>else</CODE>, followed
|
|
by a series of commands that are only executed if the expression
|
|
was false. The end of the list is marked by a line containing <CODE>end</CODE>.
|
|
|
|
<A NAME="IDX648"></A>
|
|
<DT><CODE>while</CODE>
|
|
<DD>
|
|
The syntax is similar to <CODE>if</CODE>: the command takes a single argument,
|
|
which is an expression to evaluate, and must be followed by the commands to
|
|
execute, one per line, terminated by an <CODE>end</CODE>.
|
|
The commands are executed repeatedly as long as the expression
|
|
evaluates to true.
|
|
|
|
<A NAME="IDX649"></A>
|
|
<DT><CODE>document <VAR>commandname</VAR></CODE>
|
|
<DD>
|
|
Document the user-defined command <VAR>commandname</VAR>, so that it can be
|
|
accessed by <CODE>help</CODE>. The command <VAR>commandname</VAR> must already be
|
|
defined. This command reads lines of documentation just as <CODE>define</CODE>
|
|
reads the lines of the command definition, ending with <CODE>end</CODE>.
|
|
After the <CODE>document</CODE> command is finished, <CODE>help</CODE> on command
|
|
<VAR>commandname</VAR> displays the documentation you have written.
|
|
|
|
You may use the <CODE>document</CODE> command again to change the
|
|
documentation of a command. Redefining the command with <CODE>define</CODE>
|
|
does not change the documentation.
|
|
|
|
<A NAME="IDX650"></A>
|
|
<DT><CODE>help user-defined</CODE>
|
|
<DD>
|
|
List all user-defined commands, with the first line of the documentation
|
|
(if any) for each.
|
|
|
|
<A NAME="IDX651"></A>
|
|
<DT><CODE>show user</CODE>
|
|
<DD>
|
|
<DT><CODE>show user <VAR>commandname</VAR></CODE>
|
|
<DD>
|
|
Display the GDB commands used to define <VAR>commandname</VAR> (but not its
|
|
documentation). If no <VAR>commandname</VAR> is given, display the
|
|
definitions for all user-defined commands.
|
|
</DL>
|
|
|
|
<P>
|
|
When user-defined commands are executed, the
|
|
commands of the definition are not printed. An error in any command
|
|
stops execution of the user-defined command.
|
|
|
|
</P>
|
|
<P>
|
|
If used interactively, commands that would ask for confirmation proceed
|
|
without asking when used inside a user-defined command. Many GDB
|
|
commands that normally print messages to say what they are doing omit the
|
|
messages when used in a user-defined command.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC147" HREF="gdb_toc.html#TOC147">User-defined command hooks</A></H2>
|
|
<P>
|
|
<A NAME="IDX652"></A>
|
|
|
|
</P>
|
|
<P>
|
|
You may define <EM>hooks</EM>, which are a special kind of user-defined
|
|
command. Whenever you run the command <SAMP>`foo'</SAMP>, if the user-defined
|
|
command <SAMP>`hook-foo'</SAMP> exists, it is executed (with no arguments)
|
|
before that command.
|
|
|
|
</P>
|
|
<P>
|
|
In addition, a pseudo-command, <SAMP>`stop'</SAMP> exists. Defining
|
|
(<SAMP>`hook-stop'</SAMP>) makes the associated commands execute every time
|
|
execution stops in your program: before breakpoint commands are run,
|
|
displays are printed, or the stack frame is printed.
|
|
|
|
</P>
|
|
<P>
|
|
For example, to ignore <CODE>SIGALRM</CODE> signals while
|
|
single-stepping, but treat them normally during normal execution,
|
|
you could define:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
define hook-stop
|
|
handle SIGALRM nopass
|
|
end
|
|
|
|
define hook-run
|
|
handle SIGALRM pass
|
|
end
|
|
|
|
define hook-continue
|
|
handle SIGLARM pass
|
|
end
|
|
</PRE>
|
|
|
|
<P>
|
|
You can define a hook for any single-word command in GDB, but
|
|
not for command aliases; you should define a hook for the basic command
|
|
name, e.g. <CODE>backtrace</CODE> rather than <CODE>bt</CODE>.
|
|
If an error occurs during the execution of your hook, execution of
|
|
GDB commands stops and GDB issues a prompt
|
|
(before the command that you actually typed had a chance to run).
|
|
|
|
</P>
|
|
<P>
|
|
If you try to define a hook which does not match any known command, you
|
|
get a warning from the <CODE>define</CODE> command.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC148" HREF="gdb_toc.html#TOC148">Command files</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX653"></A>
|
|
A command file for GDB is a file of lines that are GDB
|
|
commands. Comments (lines starting with <KBD>#</KBD>) may also be included.
|
|
An empty line in a command file does nothing; it does not mean to repeat
|
|
the last command, as it would from the terminal.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX654"></A>
|
|
<A NAME="IDX655"></A>
|
|
When you start GDB, it automatically executes commands from its
|
|
<STRONG>init files</STRONG>. These are files named <TT>`.gdbinit'</TT>.
|
|
GDB reads the init file (if any) in your home directory, then
|
|
processes command line options and operands, and then reads the init
|
|
file (if any) in the current working directory. This is so the init
|
|
file in your home directory can set options (such as <CODE>set
|
|
complaints</CODE>) which affect the processing of the command line options and
|
|
operands. The init files are not executed if you use the <SAMP>`-nx'</SAMP>
|
|
option; see section <A HREF="gdb.html#SEC8">Choosing modes</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX656"></A>
|
|
On some configurations of GDB, the init file is known by a
|
|
different name (these are typically environments where a specialized
|
|
form of GDB may need to coexist with other forms,
|
|
hence a different name
|
|
for the specialized version's init file). These are the environments
|
|
with special init file names:
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX657"></A>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
VxWorks (Wind River Systems real-time OS): <SAMP>`.vxgdbinit'</SAMP>
|
|
|
|
<A NAME="IDX658"></A>
|
|
<LI>
|
|
|
|
OS68K (Enea Data Systems real-time OS): <SAMP>`.os68gdbinit'</SAMP>
|
|
|
|
<A NAME="IDX659"></A>
|
|
<LI>
|
|
|
|
ES-1800 (Ericsson Telecom AB M68000 emulator): <SAMP>`.esgdbinit'</SAMP>
|
|
</UL>
|
|
|
|
<P>
|
|
You can also request the execution of a command file with the
|
|
<CODE>source</CODE> command:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>source <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX660"></A>
|
|
|
|
Execute the command file <VAR>filename</VAR>.
|
|
</DL>
|
|
|
|
<P>
|
|
The lines in a command file are executed sequentially. They are not
|
|
printed as they are executed. An error in any command terminates execution
|
|
of the command file.
|
|
|
|
</P>
|
|
<P>
|
|
Commands that would ask for confirmation if used interactively proceed
|
|
without asking when used in a command file. Many GDB commands that
|
|
normally print messages to say what they are doing omit the messages
|
|
when called from command files.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC149" HREF="gdb_toc.html#TOC149">Commands for controlled output</A></H2>
|
|
|
|
<P>
|
|
During the execution of a command file or a user-defined command, normal
|
|
GDB output is suppressed; the only output that appears is what is
|
|
explicitly printed by the commands in the definition. This section
|
|
describes three commands useful for generating exactly the output you
|
|
want.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>echo <VAR>text</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX661"></A>
|
|
|
|
Print <VAR>text</VAR>. Nonprinting characters can be included in
|
|
<VAR>text</VAR> using C escape sequences, such as <SAMP>`\n'</SAMP> to print a
|
|
newline. <STRONG>No newline is printed unless you specify one.</STRONG>
|
|
In addition to the standard C escape sequences, a backslash followed
|
|
by a space stands for a space. This is useful for displaying a
|
|
string with spaces at the beginning or the end, since leading and
|
|
trailing spaces are otherwise trimmed from all arguments.
|
|
To print <SAMP>` and foo = '</SAMP>, use the command
|
|
<SAMP>`echo \ and foo = \ '</SAMP>.
|
|
|
|
A backslash at the end of <VAR>text</VAR> can be used, as in C, to continue
|
|
the command onto subsequent lines. For example,
|
|
|
|
|
|
<PRE>
|
|
echo This is some text\n\
|
|
which is continued\n\
|
|
onto several lines.\n
|
|
</PRE>
|
|
|
|
produces the same output as
|
|
|
|
|
|
<PRE>
|
|
echo This is some text\n
|
|
echo which is continued\n
|
|
echo onto several lines.\n
|
|
</PRE>
|
|
|
|
<A NAME="IDX662"></A>
|
|
<DT><CODE>output <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
Print the value of <VAR>expression</VAR> and nothing but that value: no
|
|
newlines, no <SAMP>`$<VAR>nn</VAR> = '</SAMP>. The value is not entered in the
|
|
value history either. See section <A HREF="gdb.html#SEC52">Expressions</A>, for more information
|
|
on expressions.
|
|
|
|
<DT><CODE>output/<VAR>fmt</VAR> <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
Print the value of <VAR>expression</VAR> in format <VAR>fmt</VAR>. You can use
|
|
the same formats as for <CODE>print</CODE>. See section <A HREF="gdb.html#SEC55">Output formats</A>, for more information.
|
|
|
|
<A NAME="IDX663"></A>
|
|
<DT><CODE>printf <VAR>string</VAR>, <VAR>expressions</VAR>...</CODE>
|
|
<DD>
|
|
Print the values of the <VAR>expressions</VAR> under the control of
|
|
<VAR>string</VAR>. The <VAR>expressions</VAR> are separated by commas and may be
|
|
either numbers or pointers. Their values are printed as specified by
|
|
<VAR>string</VAR>, exactly as if your program were to execute the C
|
|
subroutine
|
|
|
|
|
|
<PRE>
|
|
printf (<VAR>string</VAR>, <VAR>expressions</VAR>...);
|
|
</PRE>
|
|
|
|
For example, you can print two values in hex like this:
|
|
|
|
|
|
<PRE>
|
|
printf "foo, bar-foo = 0x%x, 0x%x\n", foo, bar-foo
|
|
</PRE>
|
|
|
|
The only backslash-escape sequences that you can use in the format
|
|
string are the simple ones that consist of backslash followed by a
|
|
letter.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC150" HREF="gdb_toc.html#TOC150">Using GDB under GNU Emacs</A></H1>
|
|
|
|
<P>
|
|
<A NAME="IDX664"></A>
|
|
<A NAME="IDX665"></A>
|
|
A special interface allows you to use GNU Emacs to view (and
|
|
edit) the source files for the program you are debugging with
|
|
GDB.
|
|
|
|
</P>
|
|
<P>
|
|
To use this interface, use the command <KBD>M-x gdb</KBD> in Emacs. Give the
|
|
executable file you want to debug as an argument. This command starts
|
|
GDB as a subprocess of Emacs, with input and output through a newly
|
|
created Emacs buffer.
|
|
|
|
</P>
|
|
<P>
|
|
Using GDB under Emacs is just like using GDB normally except for two
|
|
things:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
All "terminal" input and output goes through the Emacs buffer.
|
|
</UL>
|
|
|
|
<P>
|
|
This applies both to GDB commands and their output, and to the input
|
|
and output done by the program you are debugging.
|
|
|
|
</P>
|
|
<P>
|
|
This is useful because it means that you can copy the text of previous
|
|
commands and input them again; you can even use parts of the output
|
|
in this way.
|
|
|
|
</P>
|
|
<P>
|
|
All the facilities of Emacs' Shell mode are available for interacting
|
|
with your program. In particular, you can send signals the usual
|
|
way--for example, <KBD>C-c C-c</KBD> for an interrupt, <KBD>C-c C-z</KBD> for a
|
|
stop.
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
GDB displays source code through Emacs.
|
|
</UL>
|
|
|
|
<P>
|
|
Each time GDB displays a stack frame, Emacs automatically finds the
|
|
source file for that frame and puts an arrow (<SAMP>`=>'</SAMP>) at the
|
|
left margin of the current line. Emacs uses a separate buffer for
|
|
source display, and splits the screen to show both your GDB session
|
|
and the source.
|
|
|
|
</P>
|
|
<P>
|
|
Explicit GDB <CODE>list</CODE> or search commands still produce output as
|
|
usual, but you probably have no reason to use them from Emacs.
|
|
|
|
</P>
|
|
|
|
<BLOCKQUOTE>
|
|
<P>
|
|
<EM>Warning:</EM> If the directory where your program resides is not your
|
|
current directory, it can be easy to confuse Emacs about the location of
|
|
the source files, in which case the auxiliary display buffer does not
|
|
appear to show your source. GDB can find programs by searching your
|
|
environment's <CODE>PATH</CODE> variable, so the GDB input and output
|
|
session proceeds normally; but Emacs does not get enough information
|
|
back from GDB to locate the source files in this situation. To
|
|
avoid this problem, either start GDB mode from the directory where
|
|
your program resides, or specify an absolute file name when prompted for the
|
|
<KBD>M-x gdb</KBD> argument.
|
|
|
|
</P>
|
|
<P>
|
|
A similar confusion can result if you use the GDB <CODE>file</CODE> command to
|
|
switch to debugging a program in some other location, from an existing
|
|
GDB buffer in Emacs.
|
|
</BLOCKQUOTE>
|
|
|
|
<P>
|
|
By default, <KBD>M-x gdb</KBD> calls the program called <TT>`gdb'</TT>. If
|
|
you need to call GDB by a different name (for example, if you keep
|
|
several configurations around, with different names) you can set the
|
|
Emacs variable <CODE>gdb-command-name</CODE>; for example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(setq gdb-command-name "mygdb")
|
|
</PRE>
|
|
|
|
<P>
|
|
(preceded by <KBD>ESC ESC</KBD>, or typed in the <CODE>*scratch*</CODE> buffer, or
|
|
in your <TT>`.emacs'</TT> file) makes Emacs call the program named
|
|
"<CODE>mygdb</CODE>" instead.
|
|
|
|
</P>
|
|
<P>
|
|
In the GDB I/O buffer, you can use these special Emacs commands in
|
|
addition to the standard Shell mode commands:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><KBD>C-h m</KBD>
|
|
<DD>
|
|
Describe the features of Emacs' GDB Mode.
|
|
|
|
<DT><KBD>M-s</KBD>
|
|
<DD>
|
|
Execute to another source line, like the GDB <CODE>step</CODE> command; also
|
|
update the display window to show the current file and location.
|
|
|
|
<DT><KBD>M-n</KBD>
|
|
<DD>
|
|
Execute to next source line in this function, skipping all function
|
|
calls, like the GDB <CODE>next</CODE> command. Then update the display window
|
|
to show the current file and location.
|
|
|
|
<DT><KBD>M-i</KBD>
|
|
<DD>
|
|
Execute one instruction, like the GDB <CODE>stepi</CODE> command; update
|
|
display window accordingly.
|
|
|
|
<DT><KBD>M-x gdb-nexti</KBD>
|
|
<DD>
|
|
Execute to next instruction, using the GDB <CODE>nexti</CODE> command; update
|
|
display window accordingly.
|
|
|
|
<DT><KBD>C-c C-f</KBD>
|
|
<DD>
|
|
Execute until exit from the selected stack frame, like the GDB
|
|
<CODE>finish</CODE> command.
|
|
|
|
<DT><KBD>M-c</KBD>
|
|
<DD>
|
|
Continue execution of your program, like the GDB <CODE>continue</CODE>
|
|
command.
|
|
|
|
<EM>Warning:</EM> In Emacs v19, this command is <KBD>C-c C-p</KBD>.
|
|
|
|
<DT><KBD>M-u</KBD>
|
|
<DD>
|
|
Go up the number of frames indicated by the numeric argument
|
|
(see section `Numeric Arguments' in <CITE>The GNU Emacs Manual</CITE>),
|
|
like the GDB <CODE>up</CODE> command.
|
|
|
|
<EM>Warning:</EM> In Emacs v19, this command is <KBD>C-c C-u</KBD>.
|
|
|
|
<DT><KBD>M-d</KBD>
|
|
<DD>
|
|
Go down the number of frames indicated by the numeric argument, like the
|
|
GDB <CODE>down</CODE> command.
|
|
|
|
<EM>Warning:</EM> In Emacs v19, this command is <KBD>C-c C-d</KBD>.
|
|
|
|
<DT><KBD>C-x &</KBD>
|
|
<DD>
|
|
Read the number where the cursor is positioned, and insert it at the end
|
|
of the GDB I/O buffer. For example, if you wish to disassemble code
|
|
around an address that was displayed earlier, type <KBD>disassemble</KBD>;
|
|
then move the cursor to the address display, and pick up the
|
|
argument for <CODE>disassemble</CODE> by typing <KBD>C-x &</KBD>.
|
|
|
|
You can customize this further by defining elements of the list
|
|
<CODE>gdb-print-command</CODE>; once it is defined, you can format or
|
|
otherwise process numbers picked up by <KBD>C-x &</KBD> before they are
|
|
inserted. A numeric argument to <KBD>C-x &</KBD> indicates that you
|
|
wish special formatting, and also acts as an index to pick an element of the
|
|
list. If the list element is a string, the number to be inserted is
|
|
formatted using the Emacs function <CODE>format</CODE>; otherwise the number
|
|
is passed as an argument to the corresponding list element.
|
|
</DL>
|
|
|
|
<P>
|
|
In any source file, the Emacs command <KBD>C-x SPC</KBD> (<CODE>gdb-break</CODE>)
|
|
tells GDB to set a breakpoint on the source line point is on.
|
|
|
|
</P>
|
|
<P>
|
|
If you accidentally delete the source-display buffer, an easy way to get
|
|
it back is to type the command <CODE>f</CODE> in the GDB buffer, to
|
|
request a frame display; when you run under Emacs, this recreates
|
|
the source buffer if necessary to show you the context of the current
|
|
frame.
|
|
|
|
</P>
|
|
<P>
|
|
The source files displayed in Emacs are in ordinary Emacs buffers
|
|
which are visiting the source files in the usual way. You can edit
|
|
the files with these buffers if you wish; but keep in mind that GDB
|
|
communicates with Emacs in terms of line numbers. If you add or
|
|
delete lines from the text, the line numbers that GDB knows cease
|
|
to correspond properly with the code.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC151" HREF="gdb_toc.html#TOC151">Reporting Bugs in GDB</A></H1>
|
|
<P>
|
|
<A NAME="IDX666"></A>
|
|
<A NAME="IDX667"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Your bug reports play an essential role in making GDB reliable.
|
|
|
|
</P>
|
|
<P>
|
|
Reporting a bug may help you by bringing a solution to your problem, or it
|
|
may not. But in any case the principal function of a bug report is to help
|
|
the entire community by making the next version of GDB work better. Bug
|
|
reports are your contribution to the maintenance of GDB.
|
|
|
|
</P>
|
|
<P>
|
|
In order for a bug report to serve its purpose, you must include the
|
|
information that enables us to fix the bug.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC152" HREF="gdb_toc.html#TOC152">Have you found a bug?</A></H2>
|
|
<P>
|
|
<A NAME="IDX668"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If you are not sure whether you have found a bug, here are some guidelines:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
<A NAME="IDX669"></A>
|
|
<A NAME="IDX670"></A>
|
|
<A NAME="IDX671"></A>
|
|
|
|
If the debugger gets a fatal signal, for any input whatever, that is a
|
|
GDB bug. Reliable debuggers never crash.
|
|
|
|
<A NAME="IDX672"></A>
|
|
<LI>
|
|
|
|
If GDB produces an error message for valid input, that is a bug.
|
|
|
|
<A NAME="IDX673"></A>
|
|
<LI>
|
|
|
|
If GDB does not produce an error message for invalid input,
|
|
that is a bug. However, you should note that your idea of
|
|
"invalid input" might be our idea of "an extension" or "support
|
|
for traditional practice".
|
|
|
|
<LI>
|
|
|
|
If you are an experienced user of debugging tools, your suggestions
|
|
for improvement of GDB are welcome in any case.
|
|
</UL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC153" HREF="gdb_toc.html#TOC153">How to report bugs</A></H2>
|
|
<P>
|
|
<A NAME="IDX674"></A>
|
|
<A NAME="IDX675"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A number of companies and individuals offer support for GNU products.
|
|
If you obtained GDB from a support organization, we recommend you
|
|
contact that organization first.
|
|
|
|
</P>
|
|
<P>
|
|
You can find contact information for many support companies and
|
|
individuals in the file <TT>`etc/SERVICE'</TT> in the GNU Emacs
|
|
distribution.
|
|
|
|
</P>
|
|
<P>
|
|
In any event, we also recommend that you send bug reports for GDB to one
|
|
of these addresses:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
bug-gdb@prep.ai.mit.edu
|
|
{ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-gdb
|
|
</PRE>
|
|
|
|
<P>
|
|
<STRONG>Do not send bug reports to <SAMP>`info-gdb'</SAMP>, or to
|
|
<SAMP>`help-gdb'</SAMP>, or to any newsgroups.</STRONG> Most users of GDB do not want to
|
|
receive bug reports. Those that do have arranged to receive <SAMP>`bug-gdb'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
The mailing list <SAMP>`bug-gdb'</SAMP> has a newsgroup <SAMP>`gnu.gdb.bug'</SAMP> which
|
|
serves as a repeater. The mailing list and the newsgroup carry exactly
|
|
the same messages. Often people think of posting bug reports to the
|
|
newsgroup instead of mailing them. This appears to work, but it has one
|
|
problem which can be crucial: a newsgroup posting often lacks a mail
|
|
path back to the sender. Thus, if we need to ask for more information,
|
|
we may be unable to reach you. For this reason, it is better to send
|
|
bug reports to the mailing list.
|
|
|
|
</P>
|
|
<P>
|
|
As a last resort, send bug reports on paper to:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
GNU Debugger Bugs
|
|
Free Software Foundation Inc.
|
|
59 Temple Place - Suite 330
|
|
Boston, MA 02111-1307
|
|
USA
|
|
</PRE>
|
|
|
|
<P>
|
|
The fundamental principle of reporting bugs usefully is this:
|
|
<STRONG>report all the facts</STRONG>. If you are not sure whether to state a
|
|
fact or leave it out, state it!
|
|
|
|
</P>
|
|
<P>
|
|
Often people omit facts because they think they know what causes the
|
|
problem and assume that some details do not matter. Thus, you might
|
|
assume that the name of the variable you use in an example does not matter.
|
|
Well, probably it does not, but one cannot be sure. Perhaps the bug is a
|
|
stray memory reference which happens to fetch from the location where that
|
|
name is stored in memory; perhaps, if the name were different, the contents
|
|
of that location would fool the debugger into doing the right thing despite
|
|
the bug. Play it safe and give a specific, complete example. That is the
|
|
easiest thing for you to do, and the most helpful.
|
|
|
|
</P>
|
|
<P>
|
|
Keep in mind that the purpose of a bug report is to enable us to fix
|
|
the bug if it is new to us.
|
|
Therefore, always write your bug reports on
|
|
the assumption that the bug has not been reported previously.
|
|
|
|
</P>
|
|
<P>
|
|
Sometimes people give a few sketchy facts and ask, "Does this ring a
|
|
bell?" Those bug reports are useless, and we urge everyone to
|
|
<EM>refuse to respond to them</EM> except to chide the sender to report
|
|
bugs properly.
|
|
|
|
</P>
|
|
<P>
|
|
To enable us to fix the bug, you should include all these things:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
The version of GDB. GDB announces it if you start with no
|
|
arguments; you can also print it at any time using <CODE>show version</CODE>.
|
|
|
|
Without this, we will not know whether there is any point in looking for
|
|
the bug in the current version of GDB.
|
|
|
|
<LI>
|
|
|
|
The type of machine you are using, and the operating system name and
|
|
version number.
|
|
|
|
<LI>
|
|
|
|
What compiler (and its version) was used to compile GDB---e.g.
|
|
"gcc--2.0".
|
|
|
|
<LI>
|
|
|
|
What compiler (and its version) was used to compile the program you
|
|
are debugging--e.g. "gcc--2.0".
|
|
|
|
<LI>
|
|
|
|
The command arguments you gave the compiler to compile your example and
|
|
observe the bug. For example, did you use <SAMP>`-O'</SAMP>? To guarantee
|
|
you will not omit something important, list them all. A copy of the
|
|
Makefile (or the output from make) is sufficient.
|
|
|
|
If we were to try to guess the arguments, we would probably guess wrong
|
|
and then we might not encounter the bug.
|
|
|
|
<LI>
|
|
|
|
A complete input script, and all necessary source files, that will
|
|
reproduce the bug.
|
|
|
|
<LI>
|
|
|
|
A description of what behavior you observe that you believe is
|
|
incorrect. For example, "It gets a fatal signal."
|
|
|
|
Of course, if the bug is that GDB gets a fatal signal, then we will
|
|
certainly notice it. But if the bug is incorrect output, we might not
|
|
notice unless it is glaringly wrong. You might as well not give us a
|
|
chance to make a mistake.
|
|
|
|
Even if the problem you experience is a fatal signal, you should still
|
|
say so explicitly. Suppose something strange is going on, such as,
|
|
your copy of GDB is out of synch, or you have encountered a
|
|
bug in the C library on your system. (This has happened!) Your copy
|
|
might crash and ours would not. If you told us to expect a crash,
|
|
then when ours fails to crash, we would know that the bug was not
|
|
happening for us. If you had not told us to expect a crash, then we
|
|
would not be able to draw any conclusion from our observations.
|
|
|
|
<LI>
|
|
|
|
If you wish to suggest changes to the GDB source, send us context
|
|
diffs. If you even discuss something in the GDB source, refer to
|
|
it by context, not by line number.
|
|
|
|
The line numbers in our development sources will not match those in your
|
|
sources. Your line numbers would convey no useful information to us.
|
|
</UL>
|
|
|
|
<P>
|
|
Here are some things that are not necessary:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
A description of the envelope of the bug.
|
|
|
|
Often people who encounter a bug spend a lot of time investigating
|
|
which changes to the input file will make the bug go away and which
|
|
changes will not affect it.
|
|
|
|
This is often time consuming and not very useful, because the way we
|
|
will find the bug is by running a single example under the debugger
|
|
with breakpoints, not by pure deduction from a series of examples.
|
|
We recommend that you save your time for something else.
|
|
|
|
Of course, if you can find a simpler example to report <EM>instead</EM>
|
|
of the original one, that is a convenience for us. Errors in the
|
|
output will be easier to spot, running under the debugger will take
|
|
less time, and so on.
|
|
|
|
However, simplification is not vital; if you do not want to do this,
|
|
report the bug anyway and send us the entire test case you used.
|
|
|
|
<LI>
|
|
|
|
A patch for the bug.
|
|
|
|
A patch for the bug does help us if it is a good one. But do not omit
|
|
the necessary information, such as the test case, on the assumption that
|
|
a patch is all we need. We might see problems with your patch and decide
|
|
to fix the problem another way, or we might not understand it at all.
|
|
|
|
Sometimes with a program as complicated as GDB it is very hard to
|
|
construct an example that will make the program follow a certain path
|
|
through the code. If you do not send us the example, we will not be able
|
|
to construct one, so we will not be able to verify that the bug is fixed.
|
|
|
|
And if we cannot understand what bug you are trying to fix, or why your
|
|
patch should be an improvement, we will not install it. A test case will
|
|
help us to understand.
|
|
|
|
<LI>
|
|
|
|
A guess about what the bug is or what it depends on.
|
|
|
|
Such guesses are usually wrong. Even we cannot guess right about such
|
|
things without first using the debugger to find the facts.
|
|
</UL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC154" HREF="gdb_toc.html#TOC154">Formatting Documentation</A></H1>
|
|
|
|
<P>
|
|
<A NAME="IDX676"></A>
|
|
<A NAME="IDX677"></A>
|
|
The GDB 4 release includes an already-formatted reference card, ready
|
|
for printing with PostScript or Ghostscript, in the <TT>`gdb'</TT>
|
|
subdirectory of the main source directory<A NAME="DOCF4" HREF="gdb_foot.html#FOOT4">(4)</A>. If you can use PostScript or Ghostscript with your printer,
|
|
you can print the reference card immediately with <TT>`refcard.ps'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
The release also includes the source for the reference card. You
|
|
can format it, using TeX, by typing:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
make refcard.dvi
|
|
</PRE>
|
|
|
|
<P>
|
|
The GDB reference card is designed to print in <STRONG>landscape</STRONG>
|
|
mode on US "letter" size paper;
|
|
that is, on a sheet 11 inches wide by 8.5 inches
|
|
high. You will need to specify this form of printing as an option to
|
|
your DVI output program.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX678"></A>
|
|
|
|
</P>
|
|
<P>
|
|
All the documentation for GDB comes as part of the machine-readable
|
|
distribution. The documentation is written in Texinfo format, which is
|
|
a documentation system that uses a single source file to produce both
|
|
on-line information and a printed manual. You can use one of the Info
|
|
formatting commands to create the on-line version of the documentation
|
|
and TeX (or <CODE>texi2roff</CODE>) to typeset the printed version.
|
|
|
|
</P>
|
|
<P>
|
|
GDB includes an already formatted copy of the on-line Info version of
|
|
this manual in the <TT>`gdb'</TT> subdirectory. The main Info file is
|
|
<TT>`gdb-version-number/gdb/gdb.info'</TT>, and it refers to
|
|
subordinate files matching <SAMP>`gdb.info*'</SAMP> in the same directory. If
|
|
necessary, you can print out these files, or read them with any editor;
|
|
but they are easier to read using the <CODE>info</CODE> subsystem in GNU Emacs
|
|
or the standalone <CODE>info</CODE> program, available as part of the GNU
|
|
Texinfo distribution.
|
|
|
|
</P>
|
|
<P>
|
|
If you want to format these Info files yourself, you need one of the
|
|
Info formatting programs, such as <CODE>texinfo-format-buffer</CODE> or
|
|
<CODE>makeinfo</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
If you have <CODE>makeinfo</CODE> installed, and are in the top level GDB
|
|
source directory (<TT>`gdb-'</TT>, in the case of version ), you can
|
|
make the Info file by typing:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
cd gdb
|
|
make gdb.info
|
|
</PRE>
|
|
|
|
<P>
|
|
If you want to typeset and print copies of this manual, you need TeX,
|
|
a program to print its DVI output files, and <TT>`texinfo.tex'</TT>, the
|
|
Texinfo definitions file.
|
|
|
|
</P>
|
|
<P>
|
|
TeX is a typesetting program; it does not print files directly, but
|
|
produces output files called DVI files. To print a typeset
|
|
document, you need a program to print DVI files. If your system
|
|
has TeX installed, chances are it has such a program. The precise
|
|
command to use depends on your system; <KBD>lpr -d</KBD> is common; another
|
|
(for PostScript devices) is <KBD>dvips</KBD>. The DVI print command may
|
|
require a file name without any extension or a <SAMP>`.dvi'</SAMP> extension.
|
|
|
|
</P>
|
|
<P>
|
|
TeX also requires a macro definitions file called
|
|
<TT>`texinfo.tex'</TT>. This file tells TeX how to typeset a document
|
|
written in Texinfo format. On its own, TeX cannot either read or
|
|
typeset a Texinfo file. <TT>`texinfo.tex'</TT> is distributed with GDB
|
|
and is located in the <TT>`gdb-<VAR>version-number</VAR>/texinfo'</TT>
|
|
directory.
|
|
|
|
</P>
|
|
<P>
|
|
If you have TeX and a DVI printer program installed, you can
|
|
typeset and print this manual. First switch to the the <TT>`gdb'</TT>
|
|
subdirectory of the main source directory (for example, to
|
|
<TT>`gdb-/gdb'</TT>) and then type:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
make gdb.dvi
|
|
</PRE>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC155" HREF="gdb_toc.html#TOC155">Installing GDB</A></H1>
|
|
<P>
|
|
<A NAME="IDX679"></A>
|
|
<A NAME="IDX680"></A>
|
|
|
|
</P>
|
|
<P>
|
|
GDB comes with a <CODE>configure</CODE> script that automates the process
|
|
of preparing GDB for installation; you can then use <CODE>make</CODE> to
|
|
build the <CODE>gdb</CODE> program.
|
|
<A NAME="DOCF5" HREF="gdb_foot.html#FOOT5">(5)</A>
|
|
|
|
</P>
|
|
<P>
|
|
The GDB distribution includes all the source code you need for
|
|
GDB in a single directory, whose name is usually composed by
|
|
appending the version number to <SAMP>`gdb'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
For example, the GDB version distribution is in the
|
|
<TT>`gdb-'</TT> directory. That directory contains:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>gdb-/configure (and supporting files)</CODE>
|
|
<DD>
|
|
script for configuring GDB and all its supporting libraries
|
|
|
|
<DT><CODE>gdb-/gdb</CODE>
|
|
<DD>
|
|
the source specific to GDB itself
|
|
|
|
<DT><CODE>gdb-/bfd</CODE>
|
|
<DD>
|
|
source for the Binary File Descriptor library
|
|
|
|
<DT><CODE>gdb-/include</CODE>
|
|
<DD>
|
|
GNU include files
|
|
|
|
<DT><CODE>gdb-/libiberty</CODE>
|
|
<DD>
|
|
source for the <SAMP>`-liberty'</SAMP> free software library
|
|
|
|
<DT><CODE>gdb-/opcodes</CODE>
|
|
<DD>
|
|
source for the library of opcode tables and disassemblers
|
|
|
|
<DT><CODE>gdb-/readline</CODE>
|
|
<DD>
|
|
source for the GNU command-line interface
|
|
|
|
<DT><CODE>gdb-/glob</CODE>
|
|
<DD>
|
|
source for the GNU filename pattern-matching subroutine
|
|
|
|
<DT><CODE>gdb-/mmalloc</CODE>
|
|
<DD>
|
|
source for the GNU memory-mapped malloc package
|
|
</DL>
|
|
|
|
<P>
|
|
The simplest way to configure and build GDB is to run <CODE>configure</CODE>
|
|
from the <TT>`gdb-<VAR>version-number</VAR>'</TT> source directory, which in
|
|
this example is the <TT>`gdb-'</TT> directory.
|
|
|
|
</P>
|
|
<P>
|
|
First switch to the <TT>`gdb-<VAR>version-number</VAR>'</TT> source directory
|
|
if you are not already in it; then run <CODE>configure</CODE>. Pass the
|
|
identifier for the platform on which GDB will run as an
|
|
argument.
|
|
|
|
</P>
|
|
<P>
|
|
For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
cd gdb-
|
|
./configure <VAR>host</VAR>
|
|
make
|
|
</PRE>
|
|
|
|
<P>
|
|
where <VAR>host</VAR> is an identifier such as <SAMP>`sun4'</SAMP> or
|
|
<SAMP>`decstation'</SAMP>, that identifies the platform where GDB will run.
|
|
(You can often leave off <VAR>host</VAR>; <CODE>configure</CODE> tries to guess the
|
|
correct value by examining your system.)
|
|
|
|
</P>
|
|
<P>
|
|
Running <SAMP>`configure <VAR>host</VAR>'</SAMP> and then running <CODE>make</CODE> builds the
|
|
<TT>`bfd'</TT>, <TT>`readline'</TT>, <TT>`mmalloc'</TT>, and <TT>`libiberty'</TT>
|
|
libraries, then <CODE>gdb</CODE> itself. The configured source files, and the
|
|
binaries, are left in the corresponding source directories.
|
|
|
|
</P>
|
|
<P>
|
|
<CODE>configure</CODE> is a Bourne-shell (<CODE>/bin/sh</CODE>) script; if your
|
|
system does not recognize this automatically when you run a different
|
|
shell, you may need to run <CODE>sh</CODE> on it explicitly:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
sh configure <VAR>host</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
If you run <CODE>configure</CODE> from a directory that contains source
|
|
directories for multiple libraries or programs, such as the
|
|
<TT>`gdb-'</TT> source directory for version , <CODE>configure</CODE>
|
|
creates configuration files for every directory level underneath (unless
|
|
you tell it not to, with the <SAMP>`--norecursion'</SAMP> option).
|
|
|
|
</P>
|
|
<P>
|
|
You can run the <CODE>configure</CODE> script from any of the
|
|
subordinate directories in the GDB distribution if you only want to
|
|
configure that subdirectory, but be sure to specify a path to it.
|
|
|
|
</P>
|
|
<P>
|
|
For example, with version , type the following to configure only
|
|
the <CODE>bfd</CODE> subdirectory:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
cd gdb-/bfd
|
|
../configure <VAR>host</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
You can install <CODE>gdb</CODE> anywhere; it has no hardwired paths.
|
|
However, you should make sure that the shell on your path (named by
|
|
the <SAMP>`SHELL'</SAMP> environment variable) is publicly readable. Remember
|
|
that GDB uses the shell to start your program--some systems refuse to
|
|
let GDB debug child processes whose programs are not readable.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC156" HREF="gdb_toc.html#TOC156">Compiling GDB in another directory</A></H2>
|
|
|
|
<P>
|
|
If you want to run GDB versions for several host or target machines,
|
|
you need a different <CODE>gdb</CODE> compiled for each combination of
|
|
host and target. <CODE>configure</CODE> is designed to make this easy by
|
|
allowing you to generate each configuration in a separate subdirectory,
|
|
rather than in the source directory. If your <CODE>make</CODE> program
|
|
handles the <SAMP>`VPATH'</SAMP> feature (GNU <CODE>make</CODE> does), running
|
|
<CODE>make</CODE> in each of these directories builds the <CODE>gdb</CODE>
|
|
program specified there.
|
|
|
|
</P>
|
|
<P>
|
|
To build <CODE>gdb</CODE> in a separate directory, run <CODE>configure</CODE>
|
|
with the <SAMP>`--srcdir'</SAMP> option to specify where to find the source.
|
|
(You also need to specify a path to find <CODE>configure</CODE>
|
|
itself from your working directory. If the path to <CODE>configure</CODE>
|
|
would be the same as the argument to <SAMP>`--srcdir'</SAMP>, you can leave out
|
|
the <SAMP>`--srcdir'</SAMP> option; it is assumed.)
|
|
|
|
</P>
|
|
<P>
|
|
For example, with version , you can build GDB in a
|
|
separate directory for a Sun 4 like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
cd gdb-
|
|
mkdir ../gdb-sun4
|
|
cd ../gdb-sun4
|
|
../gdb-/configure sun4
|
|
make
|
|
</PRE>
|
|
|
|
<P>
|
|
When <CODE>configure</CODE> builds a configuration using a remote source
|
|
directory, it creates a tree for the binaries with the same structure
|
|
(and using the same names) as the tree under the source directory. In
|
|
the example, you'd find the Sun 4 library <TT>`libiberty.a'</TT> in the
|
|
directory <TT>`gdb-sun4/libiberty'</TT>, and GDB itself in
|
|
<TT>`gdb-sun4/gdb'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
One popular reason to build several GDB configurations in separate
|
|
directories is to configure GDB for cross-compiling (where
|
|
GDB runs on one machine--the <STRONG>host</STRONG>---while debugging
|
|
programs that run on another machine--the <STRONG>target</STRONG>).
|
|
You specify a cross-debugging target by
|
|
giving the <SAMP>`--target=<VAR>target</VAR>'</SAMP> option to <CODE>configure</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
When you run <CODE>make</CODE> to build a program or library, you must run
|
|
it in a configured directory--whatever directory you were in when you
|
|
called <CODE>configure</CODE> (or one of its subdirectories).
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>Makefile</CODE> that <CODE>configure</CODE> generates in each source
|
|
directory also runs recursively. If you type <CODE>make</CODE> in a source
|
|
directory such as <TT>`gdb-'</TT> (or in a separate configured
|
|
directory configured with <SAMP>`--srcdir=<VAR>dirname</VAR>/gdb-'</SAMP>), you
|
|
will build all the required libraries, and then build GDB.
|
|
|
|
</P>
|
|
<P>
|
|
When you have multiple hosts or targets configured in separate
|
|
directories, you can run <CODE>make</CODE> on them in parallel (for example,
|
|
if they are NFS-mounted on each of the hosts); they will not interfere
|
|
with each other.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC157" HREF="gdb_toc.html#TOC157">Specifying names for hosts and targets</A></H2>
|
|
|
|
<P>
|
|
The specifications used for hosts and targets in the <CODE>configure</CODE>
|
|
script are based on a three-part naming scheme, but some short predefined
|
|
aliases are also supported. The full naming scheme encodes three pieces
|
|
of information in the following pattern:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>architecture</VAR>-<VAR>vendor</VAR>-<VAR>os</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
For example, you can use the alias <CODE>sun4</CODE> as a <VAR>host</VAR> argument,
|
|
or as the value for <VAR>target</VAR> in a <CODE>--target=<VAR>target</VAR></CODE>
|
|
option. The equivalent full name is <SAMP>`sparc-sun-sunos4'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>configure</CODE> script accompanying GDB does not provide
|
|
any query facility to list all supported host and target names or
|
|
aliases. <CODE>configure</CODE> calls the Bourne shell script
|
|
<CODE>config.sub</CODE> to map abbreviations to full names; you can read the
|
|
script, if you wish, or you can use it to test your guesses on
|
|
abbreviations--for example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
% sh config.sub sun4
|
|
sparc-sun-sunos4.1.1
|
|
% sh config.sub sun3
|
|
m68k-sun-sunos4.1.1
|
|
% sh config.sub decstation
|
|
mips-dec-ultrix4.2
|
|
% sh config.sub hp300bsd
|
|
m68k-hp-bsd
|
|
% sh config.sub i386v
|
|
i386-unknown-sysv
|
|
% sh config.sub i786v
|
|
Invalid configuration `i786v': machine `i786v' not recognized
|
|
</PRE>
|
|
|
|
<P>
|
|
<CODE>config.sub</CODE> is also distributed in the GDB source
|
|
directory (<TT>`gdb-'</TT>, for version ).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC158" HREF="gdb_toc.html#TOC158"><CODE>configure</CODE> options</A></H2>
|
|
|
|
<P>
|
|
Here is a summary of the <CODE>configure</CODE> options and arguments that
|
|
are most often useful for building GDB. <CODE>configure</CODE> also has
|
|
several other options not listed here. See Info file `configure.info', node `What Configure Does', for a full explanation of <CODE>configure</CODE>.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
configure [--help]
|
|
[--prefix=<VAR>dir</VAR>]
|
|
[--srcdir=<VAR>dirname</VAR>]
|
|
[--norecursion] [--rm]
|
|
[--target=<VAR>target</VAR>] <VAR>host</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
You may introduce options with a single <SAMP>`-'</SAMP> rather than
|
|
<SAMP>`--'</SAMP> if you prefer; but you may abbreviate option names if you use
|
|
<SAMP>`--'</SAMP>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>--help</CODE>
|
|
<DD>
|
|
Display a quick summary of how to invoke <CODE>configure</CODE>.
|
|
|
|
<DT><CODE>-prefix=<VAR>dir</VAR></CODE>
|
|
<DD>
|
|
Configure the source to install programs and files under directory
|
|
<TT>`<VAR>dir</VAR>'</TT>.
|
|
|
|
<DT><CODE>--srcdir=<VAR>dirname</VAR></CODE>
|
|
<DD>
|
|
<STRONG>Warning: using this option requires GNU <CODE>make</CODE>, or another
|
|
<CODE>make</CODE> that implements the <CODE>VPATH</CODE> feature.</STRONG><BR>
|
|
Use this option to make configurations in directories separate from the
|
|
GDB source directories. Among other things, you can use this to
|
|
build (or maintain) several configurations simultaneously, in separate
|
|
directories. <CODE>configure</CODE> writes configuration specific files in
|
|
the current directory, but arranges for them to use the source in the
|
|
directory <VAR>dirname</VAR>. <CODE>configure</CODE> creates directories under
|
|
the working directory in parallel to the source directories below
|
|
<VAR>dirname</VAR>.
|
|
|
|
<DT><CODE>--norecursion</CODE>
|
|
<DD>
|
|
Configure only the directory level where <CODE>configure</CODE> is executed; do not
|
|
propagate configuration to subdirectories.
|
|
|
|
<DT><CODE>--rm</CODE>
|
|
<DD>
|
|
<EM>Remove</EM> files otherwise built during configuration.
|
|
|
|
<DT><CODE>--target=<VAR>target</VAR></CODE>
|
|
<DD>
|
|
Configure GDB for cross-debugging programs running on the specified
|
|
<VAR>target</VAR>. Without this option, GDB is configured to debug
|
|
programs that run on the same machine (<VAR>host</VAR>) as GDB itself.
|
|
|
|
There is no convenient way to generate a list of all available targets.
|
|
|
|
<DT><CODE><VAR>host</VAR> ...</CODE>
|
|
<DD>
|
|
Configure GDB to run on the specified <VAR>host</VAR>.
|
|
|
|
There is no convenient way to generate a list of all available hosts.
|
|
</DL>
|
|
|
|
<P>
|
|
<CODE>configure</CODE> accepts other options, for compatibility with
|
|
configuring other GNU tools recursively; but these are the only
|
|
options that affect GDB or its supporting libraries.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC159" HREF="gdb_toc.html#TOC159">Index</A></H1>
|
|
|
|
<P>
|
|
<H2>#</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX14">#</A>
|
|
<LI><A HREF="gdb.html#IDX387"><CODE>#</CODE> in Modula-2</A>
|
|
</DIR>
|
|
<H2>$</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX309"><CODE>$</CODE></A>
|
|
<LI><A HREF="gdb.html#IDX310"><CODE>$$</CODE></A>
|
|
<LI><A HREF="gdb.html#IDX315">$_</A>
|
|
<LI><A HREF="gdb.html#IDX104"><CODE>$_</CODE> and <CODE>info breakpoints</CODE></A>
|
|
<LI><A HREF="gdb.html#IDX230"><CODE>$_</CODE> and <CODE>info line</CODE></A>
|
|
<LI><A HREF="gdb.html#IDX263"><CODE>$_</CODE>, <CODE>$__</CODE>, and value history</A>
|
|
<LI><A HREF="gdb.html#IDX316">$__</A>
|
|
<LI><A HREF="gdb.html#IDX317">$_exitcode</A>
|
|
<LI><A HREF="gdb.html#IDX96">$bpnum</A>
|
|
<LI><A HREF="gdb.html#IDX221">$cdir</A>
|
|
<LI><A HREF="gdb.html#IDX222">$cwd</A>
|
|
</DIR>
|
|
<H2>.</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX384">.</A>
|
|
<LI><A HREF="gdb.html#IDX659">.esgdbinit</A>
|
|
<LI><A HREF="gdb.html#IDX655"><TT>`.gdbinit'</TT></A>
|
|
<LI><A HREF="gdb.html#IDX658">.os68gdbinit</A>
|
|
<LI><A HREF="gdb.html#IDX657">.vxgdbinit</A>
|
|
</DIR>
|
|
<H2>/</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX61">/proc</A>
|
|
</DIR>
|
|
<H2>:</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX252">::</A>, <A HREF="gdb.html#IDX386">::</A>
|
|
</DIR>
|
|
<H2>@</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX257">@</A>
|
|
</DIR>
|
|
<H2>a</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX356">a.out and C++</A>
|
|
<LI><A HREF="gdb.html#IDX11">abbreviation</A>
|
|
<LI><A HREF="gdb.html#IDX456">active targets</A>
|
|
<LI><A HREF="gdb.html#IDX443">add-shared-symbol-file</A>
|
|
<LI><A HREF="gdb.html#IDX441">add-symbol-file</A>
|
|
<LI><A HREF="gdb.html#IDX323">AMD 29K register stack</A>
|
|
<LI><A HREF="gdb.html#IDX467">AMD EB29K</A>
|
|
<LI><A HREF="gdb.html#IDX540">AMD29K via UDI</A>
|
|
<LI><A HREF="gdb.html#IDX39">arguments (to your program)</A>
|
|
<LI><A HREF="gdb.html#IDX256">artificial array</A>
|
|
<LI><A HREF="gdb.html#IDX232">assembly instructions</A>, <A HREF="gdb.html#IDX237">assembly instructions</A>
|
|
<LI><A HREF="gdb.html#IDX406">assignment</A>
|
|
<LI><A HREF="gdb.html#IDX57">attach</A>, <A HREF="gdb.html#IDX58">attach</A>
|
|
<LI><A HREF="gdb.html#IDX264">automatic display</A>
|
|
<LI><A HREF="gdb.html#IDX80">automatic thread selection</A>
|
|
<LI><A HREF="gdb.html#IDX111">awatch</A>
|
|
</DIR>
|
|
<H2>b</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX95">b</A>
|
|
<LI><A HREF="gdb.html#IDX183">backtrace</A>
|
|
<LI><A HREF="gdb.html#IDX94">break</A>
|
|
<LI><A HREF="gdb.html#IDX166">break ... thread <VAR>threadno</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX370">break in overloaded functions</A>
|
|
<LI><A HREF="gdb.html#IDX136">breakpoint commands</A>
|
|
<LI><A HREF="gdb.html#IDX132">breakpoint conditions</A>
|
|
<LI><A HREF="gdb.html#IDX92">breakpoint numbers</A>
|
|
<LI><A HREF="gdb.html#IDX90">breakpoint on memory address</A>
|
|
<LI><A HREF="gdb.html#IDX91">breakpoint on variable modification</A>
|
|
<LI><A HREF="gdb.html#IDX508"><CODE>breakpoint</CODE> subroutine, remote</A>
|
|
<LI><A HREF="gdb.html#IDX87">breakpoints</A>
|
|
<LI><A HREF="gdb.html#IDX164">breakpoints and threads</A>
|
|
<LI><A HREF="gdb.html#IDX184">bt</A>
|
|
<LI><A HREF="gdb.html#IDX668">bug criteria</A>
|
|
<LI><A HREF="gdb.html#IDX674">bug reports</A>
|
|
<LI><A HREF="gdb.html#IDX666">bugs in GDB</A>
|
|
</DIR>
|
|
<H2>c</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX146">c</A>
|
|
<LI><A HREF="gdb.html#IDX344">C and C++</A>
|
|
<LI><A HREF="gdb.html#IDX368">C and C++ checks</A>
|
|
<LI><A HREF="gdb.html#IDX350">C and C++ constants</A>
|
|
<LI><A HREF="gdb.html#IDX367">C and C++ defaults</A>
|
|
<LI><A HREF="gdb.html#IDX349">C and C++ operators</A>
|
|
<LI><A HREF="gdb.html#IDX346">C++</A>
|
|
<LI><A HREF="gdb.html#IDX354">C++ and object formats</A>
|
|
<LI><A HREF="gdb.html#IDX372">C++ exception handling</A>
|
|
<LI><A HREF="gdb.html#IDX253">C++ scope resolution</A>
|
|
<LI><A HREF="gdb.html#IDX352">C++ support, not in COFF</A>
|
|
<LI><A HREF="gdb.html#IDX299">C++ symbol decoding style</A>
|
|
<LI><A HREF="gdb.html#IDX374">C++ symbol display</A>
|
|
<LI><A HREF="gdb.html#IDX415">call</A>
|
|
<LI><A HREF="gdb.html#IDX364">call overloaded functions</A>
|
|
<LI><A HREF="gdb.html#IDX171">call stack</A>
|
|
<LI><A HREF="gdb.html#IDX414">calling functions</A>
|
|
<LI><A HREF="gdb.html#IDX10">calling make</A>
|
|
<LI><A HREF="gdb.html#IDX249">casts, to view memory</A>
|
|
<LI><A HREF="gdb.html#IDX116">catch</A>
|
|
<LI><A HREF="gdb.html#IDX200">catch exceptions</A>
|
|
<LI><A HREF="gdb.html#IDX49">cd</A>
|
|
<LI><A HREF="gdb.html#IDX219">cdir</A>
|
|
<LI><A HREF="gdb.html#IDX340">checks, range</A>
|
|
<LI><A HREF="gdb.html#IDX335">checks, type</A>
|
|
<LI><A HREF="gdb.html#IDX528">checksum, for GDB remote</A>
|
|
<LI><A HREF="gdb.html#IDX480">choosing target byte order</A>
|
|
<LI><A HREF="gdb.html#IDX120">clear</A>
|
|
<LI><A HREF="gdb.html#IDX118">clearing breakpoints, watchpoints</A>
|
|
<LI><A HREF="gdb.html#IDX353">COFF versus C++</A>
|
|
<LI><A HREF="gdb.html#IDX385">colon, doubled as scope operator</A>
|
|
<LI><A HREF="gdb.html#IDX251">colon-colon</A>
|
|
<LI><A HREF="gdb.html#IDX652">command files</A>, <A HREF="gdb.html#IDX653">command files</A>
|
|
<LI><A HREF="gdb.html#IDX607">command line editing</A>
|
|
<LI><A HREF="gdb.html#IDX137">commands</A>
|
|
<LI><A HREF="gdb.html#IDX369">commands for C++</A>
|
|
<LI><A HREF="gdb.html#IDX550">commands to STDBUG (ST2000)</A>
|
|
<LI><A HREF="gdb.html#IDX15">comment</A>
|
|
<LI><A HREF="gdb.html#IDX223">compilation directory</A>
|
|
<LI><A HREF="gdb.html#IDX559">Compiling</A>
|
|
<LI><A HREF="gdb.html#IDX23">complete</A>
|
|
<LI><A HREF="gdb.html#IDX16">completion</A>
|
|
<LI><A HREF="gdb.html#IDX19">completion of quoted strings</A>
|
|
<LI><A HREF="gdb.html#IDX133">condition</A>
|
|
<LI><A HREF="gdb.html#IDX131">conditional breakpoints</A>
|
|
<LI><A HREF="gdb.html#IDX679">configuring GDB</A>
|
|
<LI><A HREF="gdb.html#IDX641">confirmation</A>
|
|
<LI><A HREF="gdb.html#IDX551">connect (to STDBUG)</A>
|
|
<LI><A HREF="gdb.html#IDX145">continue</A>
|
|
<LI><A HREF="gdb.html#IDX143">continuing</A>
|
|
<LI><A HREF="gdb.html#IDX169">continuing threads</A>
|
|
<LI><A HREF="gdb.html#IDX512">control C, and remote debugging</A>
|
|
<LI><A HREF="gdb.html#IDX56">controlling terminal</A>
|
|
<LI><A HREF="gdb.html#IDX313">convenience variables</A>
|
|
<LI><A HREF="gdb.html#IDX433">core</A>
|
|
<LI><A HREF="gdb.html#IDX422">core dump file</A>
|
|
<LI><A HREF="gdb.html#IDX434">core-file</A>
|
|
<LI><A HREF="gdb.html#IDX600">CPU simulator</A>
|
|
<LI><A HREF="gdb.html#IDX671">crash of debugger</A>
|
|
<LI><A HREF="gdb.html#IDX224">current directory</A>
|
|
<LI><A HREF="gdb.html#IDX72">current thread</A>
|
|
<LI><A HREF="gdb.html#IDX220">cwd</A>
|
|
</DIR>
|
|
<H2>d</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX123">d</A>
|
|
<LI><A HREF="gdb.html#IDX670">debugger crash</A>
|
|
<LI><A HREF="gdb.html#IDX34">debugging optimized code</A>
|
|
<LI><A HREF="gdb.html#IDX522">debugging stub, example</A>
|
|
<LI><A HREF="gdb.html#IDX453">debugging target</A>
|
|
<LI><A HREF="gdb.html#IDX645">define</A>
|
|
<LI><A HREF="gdb.html#IDX122">delete</A>
|
|
<LI><A HREF="gdb.html#IDX121">delete breakpoints</A>
|
|
<LI><A HREF="gdb.html#IDX267">delete display</A>
|
|
<LI><A HREF="gdb.html#IDX119">deleting breakpoints, watchpoints</A>
|
|
<LI><A HREF="gdb.html#IDX293">demangling</A>
|
|
<LI><A HREF="gdb.html#IDX59">detach</A>
|
|
<LI><A HREF="gdb.html#IDX563">device</A>
|
|
<LI><A HREF="gdb.html#IDX218">dir</A>
|
|
<LI><A HREF="gdb.html#IDX216">directories for source files</A>
|
|
<LI><A HREF="gdb.html#IDX217">directory</A>
|
|
<LI><A HREF="gdb.html#IDX227">directory, compilation</A>
|
|
<LI><A HREF="gdb.html#IDX226">directory, current</A>
|
|
<LI><A HREF="gdb.html#IDX128">dis</A>
|
|
<LI><A HREF="gdb.html#IDX127">disable</A>
|
|
<LI><A HREF="gdb.html#IDX124">disable breakpoints</A>, <A HREF="gdb.html#IDX126">disable breakpoints</A>
|
|
<LI><A HREF="gdb.html#IDX269">disable display</A>
|
|
<LI><A HREF="gdb.html#IDX231">disassemble</A>
|
|
<LI><A HREF="gdb.html#IDX266">display</A>
|
|
<LI><A HREF="gdb.html#IDX265">display of expressions</A>
|
|
<LI><A HREF="gdb.html#IDX192">do</A>
|
|
<LI><A HREF="gdb.html#IDX649">document</A>
|
|
<LI><A HREF="gdb.html#IDX678">documentation</A>
|
|
<LI><A HREF="gdb.html#IDX191">down</A>
|
|
<LI><A HREF="gdb.html#IDX193">down-silently</A>
|
|
<LI><A HREF="gdb.html#IDX437">download to H8/300 or H8/500</A>
|
|
<LI><A HREF="gdb.html#IDX439">download to Hitachi SH</A>
|
|
<LI><A HREF="gdb.html#IDX436">download to Nindy-960</A>
|
|
<LI><A HREF="gdb.html#IDX561">download to Sparclet</A>
|
|
<LI><A HREF="gdb.html#IDX555">download to VxWorks</A>
|
|
<LI><A HREF="gdb.html#IDX442">dynamic linking</A>
|
|
</DIR>
|
|
<H2>e</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX545">eb.log</A>
|
|
<LI><A HREF="gdb.html#IDX542">EB29K board</A>
|
|
<LI><A HREF="gdb.html#IDX544">EBMON</A>
|
|
<LI><A HREF="gdb.html#IDX661">echo</A>
|
|
<LI><A HREF="gdb.html#IDX357">ECOFF and C++</A>
|
|
<LI><A HREF="gdb.html#IDX609">editing</A>
|
|
<LI><A HREF="gdb.html#IDX360">ELF/DWARF and C++</A>
|
|
<LI><A HREF="gdb.html#IDX359">ELF/stabs and C++</A>
|
|
<LI><A HREF="gdb.html#IDX647">else</A>
|
|
<LI><A HREF="gdb.html#IDX664">Emacs</A>
|
|
<LI><A HREF="gdb.html#IDX130">enable</A>
|
|
<LI><A HREF="gdb.html#IDX125">enable breakpoints</A>, <A HREF="gdb.html#IDX129">enable breakpoints</A>
|
|
<LI><A HREF="gdb.html#IDX270">enable display</A>
|
|
<LI><A HREF="gdb.html#IDX138">end</A>
|
|
<LI><A HREF="gdb.html#IDX630">entering numbers</A>
|
|
<LI><A HREF="gdb.html#IDX42">environment (of your program)</A>
|
|
<LI><A HREF="gdb.html#IDX672">error on valid input</A>
|
|
<LI><A HREF="gdb.html#IDX242">examining data</A>
|
|
<LI><A HREF="gdb.html#IDX261">examining memory</A>
|
|
<LI><A HREF="gdb.html#IDX115">exception handlers</A>, <A HREF="gdb.html#IDX201">exception handlers</A>
|
|
<LI><A HREF="gdb.html#IDX514">exceptionHandler</A>
|
|
<LI><A HREF="gdb.html#IDX425">exec-file</A>
|
|
<LI><A HREF="gdb.html#IDX423">executable file</A>
|
|
<LI><A HREF="gdb.html#IDX2">exiting GDB</A>
|
|
<LI><A HREF="gdb.html#IDX245">expressions</A>
|
|
<LI><A HREF="gdb.html#IDX345">expressions in C or C++</A>
|
|
<LI><A HREF="gdb.html#IDX351">expressions in C++</A>
|
|
<LI><A HREF="gdb.html#IDX376">expressions in Modula-2</A>
|
|
</DIR>
|
|
<H2>f</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX189">f</A>
|
|
<LI><A HREF="gdb.html#IDX669">fatal signal</A>
|
|
<LI><A HREF="gdb.html#IDX160">fatal signals</A>
|
|
<LI><A HREF="gdb.html#IDX147">fg</A>
|
|
<LI><A HREF="gdb.html#IDX424">file</A>
|
|
<LI><A HREF="gdb.html#IDX152">finish</A>
|
|
<LI><A HREF="gdb.html#IDX640">flinching</A>
|
|
<LI><A HREF="gdb.html#IDX326">floating point</A>
|
|
<LI><A HREF="gdb.html#IDX321">floating point registers</A>
|
|
<LI><A HREF="gdb.html#IDX582">floating point, MIPS remote</A>
|
|
<LI><A HREF="gdb.html#IDX515">flush_i_cache</A>
|
|
<LI><A HREF="gdb.html#IDX71">focus of debugging</A>
|
|
<LI><A HREF="gdb.html#IDX452">foo</A>
|
|
<LI><A HREF="gdb.html#IDX83">fork, debugging programs which call</A>
|
|
<LI><A HREF="gdb.html#IDX272">format options</A>
|
|
<LI><A HREF="gdb.html#IDX258">formatted output</A>
|
|
<LI><A HREF="gdb.html#IDX1">Fortran</A>
|
|
<LI><A HREF="gdb.html#IDX214">forward-search</A>
|
|
<LI><A HREF="gdb.html#IDX173">frame</A>, <A HREF="gdb.html#IDX181">frame</A>, <A HREF="gdb.html#IDX188">frame</A>
|
|
<LI><A HREF="gdb.html#IDX179">frame number</A>
|
|
<LI><A HREF="gdb.html#IDX178">frame pointer</A>
|
|
<LI><A HREF="gdb.html#IDX180">frameless execution</A>
|
|
<LI><A HREF="gdb.html#IDX501">Fujitsu</A>
|
|
</DIR>
|
|
<H2>g</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX347">g++</A>
|
|
<LI><A HREF="gdb.html#IDX675">GDB bugs, reporting</A>
|
|
<LI><A HREF="gdb.html#IDX676">GDB reference card</A>
|
|
<LI><A HREF="gdb.html#IDX614">GDBHISTFILE</A>
|
|
<LI><A HREF="gdb.html#IDX535">gdbserve.nlm</A>
|
|
<LI><A HREF="gdb.html#IDX533">gdbserver</A>
|
|
<LI><A HREF="gdb.html#IDX510">getDebugChar</A>
|
|
<LI><A HREF="gdb.html#IDX348">GNU C++</A>
|
|
<LI><A HREF="gdb.html#IDX665">GNU Emacs</A>
|
|
</DIR>
|
|
<H2>h</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX22">h</A>
|
|
<LI><A HREF="gdb.html#IDX438">H8/300 or H8/500 download</A>
|
|
<LI><A HREF="gdb.html#IDX597">H8/300 or H8/500 simulator</A>
|
|
<LI><A HREF="gdb.html#IDX163">handle</A>
|
|
<LI><A HREF="gdb.html#IDX506">handle_exception</A>
|
|
<LI><A HREF="gdb.html#IDX161">handling signals</A>
|
|
<LI><A HREF="gdb.html#IDX99">hbreak</A>
|
|
<LI><A HREF="gdb.html#IDX21">help</A>
|
|
<LI><A HREF="gdb.html#IDX458">help target</A>
|
|
<LI><A HREF="gdb.html#IDX650">help user-defined</A>
|
|
<LI><A HREF="gdb.html#IDX205"><CODE>heuristic-fence-post</CODE> (MIPS)</A>
|
|
<LI><A HREF="gdb.html#IDX619">history expansion</A>
|
|
<LI><A HREF="gdb.html#IDX612">history file</A>
|
|
<LI><A HREF="gdb.html#IDX311">history number</A>
|
|
<LI><A HREF="gdb.html#IDX615">history save</A>
|
|
<LI><A HREF="gdb.html#IDX617">history size</A>
|
|
<LI><A HREF="gdb.html#IDX611">history substitution</A>
|
|
<LI><A HREF="gdb.html#IDX496">Hitachi</A>
|
|
<LI><A HREF="gdb.html#IDX440">Hitachi SH download</A>
|
|
<LI><A HREF="gdb.html#IDX599">Hitachi SH simulator</A>
|
|
</DIR>
|
|
<H2>i</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX25">i</A>
|
|
<LI><A HREF="gdb.html#IDX52">i/o</A>
|
|
<LI><A HREF="gdb.html#IDX491">i386</A>
|
|
<LI><A HREF="gdb.html#IDX489">i386-stub.c</A>
|
|
<LI><A HREF="gdb.html#IDX537">i960</A>
|
|
<LI><A HREF="gdb.html#IDX646">if</A>
|
|
<LI><A HREF="gdb.html#IDX135">ignore</A>
|
|
<LI><A HREF="gdb.html#IDX134">ignore count (of breakpoint)</A>
|
|
<LI><A HREF="gdb.html#IDX554">INCLUDE_RDB</A>
|
|
<LI><A HREF="gdb.html#IDX24">info</A>
|
|
<LI><A HREF="gdb.html#IDX391">info address</A>
|
|
<LI><A HREF="gdb.html#IDX320">info all-registers</A>
|
|
<LI><A HREF="gdb.html#IDX197">info args</A>
|
|
<LI><A HREF="gdb.html#IDX103">info breakpoints</A>
|
|
<LI><A HREF="gdb.html#IDX199">info catch</A>
|
|
<LI><A HREF="gdb.html#IDX271">info display</A>
|
|
<LI><A HREF="gdb.html#IDX196">info f</A>
|
|
<LI><A HREF="gdb.html#IDX445">info files</A>
|
|
<LI><A HREF="gdb.html#IDX327">info float</A>
|
|
<LI><A HREF="gdb.html#IDX195">info frame</A>, <A HREF="gdb.html#IDX332">info frame</A>
|
|
<LI><A HREF="gdb.html#IDX397">info functions</A>
|
|
<LI><A HREF="gdb.html#IDX229">info line</A>
|
|
<LI><A HREF="gdb.html#IDX198">info locals</A>
|
|
<LI><A HREF="gdb.html#IDX63">info proc</A>
|
|
<LI><A HREF="gdb.html#IDX66">info proc id</A>
|
|
<LI><A HREF="gdb.html#IDX64">info proc mappings</A>
|
|
<LI><A HREF="gdb.html#IDX67">info proc status</A>
|
|
<LI><A HREF="gdb.html#IDX65">info proc times</A>
|
|
<LI><A HREF="gdb.html#IDX86">info program</A>
|
|
<LI><A HREF="gdb.html#IDX319">info registers</A>
|
|
<LI><A HREF="gdb.html#IDX187">info s</A>
|
|
<LI><A HREF="gdb.html#IDX28">info set</A>
|
|
<LI><A HREF="gdb.html#IDX449">info share</A>
|
|
<LI><A HREF="gdb.html#IDX448">info sharedlibrary</A>
|
|
<LI><A HREF="gdb.html#IDX162">info signals</A>
|
|
<LI><A HREF="gdb.html#IDX333">info source</A>, <A HREF="gdb.html#IDX395">info source</A>
|
|
<LI><A HREF="gdb.html#IDX396">info sources</A>
|
|
<LI><A HREF="gdb.html#IDX186">info stack</A>
|
|
<LI><A HREF="gdb.html#IDX446">info target</A>
|
|
<LI><A HREF="gdb.html#IDX54">info terminal</A>
|
|
<LI><A HREF="gdb.html#IDX77">info threads</A>
|
|
<LI><A HREF="gdb.html#IDX394">info types</A>
|
|
<LI><A HREF="gdb.html#IDX398">info variables</A>
|
|
<LI><A HREF="gdb.html#IDX112">info watchpoints</A>
|
|
<LI><A HREF="gdb.html#IDX373">inheritance</A>
|
|
<LI><A HREF="gdb.html#IDX654">init file</A>
|
|
<LI><A HREF="gdb.html#IDX656">init file name</A>
|
|
<LI><A HREF="gdb.html#IDX175">initial frame</A>
|
|
<LI><A HREF="gdb.html#IDX177">innermost frame</A>
|
|
<LI><A HREF="gdb.html#IDX244">inspect</A>
|
|
<LI><A HREF="gdb.html#IDX680">installation</A>
|
|
<LI><A HREF="gdb.html#IDX233">instructions, assembly</A>, <A HREF="gdb.html#IDX238">instructions, assembly</A>
|
|
<LI><A HREF="gdb.html#IDX490">Intel</A>
|
|
<LI><A HREF="gdb.html#IDX106">internal GDB breakpoints</A>
|
|
<LI><A HREF="gdb.html#IDX6">interrupt</A>
|
|
<LI><A HREF="gdb.html#IDX520">interrupting remote programs</A>
|
|
<LI><A HREF="gdb.html#IDX513">interrupting remote targets</A>
|
|
<LI><A HREF="gdb.html#IDX673">invalid input</A>
|
|
</DIR>
|
|
<H2>j</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX410">jump</A>
|
|
</DIR>
|
|
<H2>k</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX60">kill</A>
|
|
</DIR>
|
|
<H2>l</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX207">l</A>
|
|
<LI><A HREF="gdb.html#IDX328">languages</A>
|
|
<LI><A HREF="gdb.html#IDX97">latest breakpoint</A>
|
|
<LI><A HREF="gdb.html#IDX3">leaving GDB</A>
|
|
<LI><A HREF="gdb.html#IDX210">linespec</A>
|
|
<LI><A HREF="gdb.html#IDX206">list</A>
|
|
<LI><A HREF="gdb.html#IDX235">listing machine instructions</A>, <A HREF="gdb.html#IDX240">listing machine instructions</A>
|
|
<LI><A HREF="gdb.html#IDX435">load <VAR>filename</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX546">log file for EB29K</A>
|
|
</DIR>
|
|
<H2>m</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX494">m680x0</A>
|
|
<LI><A HREF="gdb.html#IDX492">m68k-stub.c</A>
|
|
<LI><A HREF="gdb.html#IDX234">machine instructions</A>, <A HREF="gdb.html#IDX239">machine instructions</A>
|
|
<LI><A HREF="gdb.html#IDX107">maint info breakpoints</A>
|
|
<LI><A HREF="gdb.html#IDX404">maint print psymbols</A>
|
|
<LI><A HREF="gdb.html#IDX402">maint print symbols</A>
|
|
<LI><A HREF="gdb.html#IDX9">make</A>
|
|
<LI><A HREF="gdb.html#IDX430">mapped</A>
|
|
<LI><A HREF="gdb.html#IDX361">member functions</A>
|
|
<LI><A HREF="gdb.html#IDX571">memory models, H8/500</A>
|
|
<LI><A HREF="gdb.html#IDX89">memory tracing</A>
|
|
<LI><A HREF="gdb.html#IDX248">memory, viewing as typed object</A>
|
|
<LI><A HREF="gdb.html#IDX431">memory-mapped symbol file</A>
|
|
<LI><A HREF="gdb.html#IDX516">memset</A>
|
|
<LI><A HREF="gdb.html#IDX572">MIPS boards</A>
|
|
<LI><A HREF="gdb.html#IDX581">MIPS remote floating point</A>
|
|
<LI><A HREF="gdb.html#IDX586">MIPS <CODE>remotedebug</CODE> protocol</A>
|
|
<LI><A HREF="gdb.html#IDX203">MIPS stack</A>
|
|
<LI><A HREF="gdb.html#IDX375">Modula-2</A>
|
|
<LI><A HREF="gdb.html#IDX378">Modula-2 built-ins</A>
|
|
<LI><A HREF="gdb.html#IDX382">Modula-2 checks</A>
|
|
<LI><A HREF="gdb.html#IDX379">Modula-2 constants</A>
|
|
<LI><A HREF="gdb.html#IDX380">Modula-2 defaults</A>
|
|
<LI><A HREF="gdb.html#IDX377">Modula-2 operators</A>
|
|
<LI><A HREF="gdb.html#IDX381">Modula-2, deviations from</A>
|
|
<LI><A HREF="gdb.html#IDX493">Motorola 680x0</A>
|
|
<LI><A HREF="gdb.html#IDX84">multiple processes</A>
|
|
<LI><A HREF="gdb.html#IDX457">multiple targets</A>
|
|
<LI><A HREF="gdb.html#IDX69">multiple threads</A>
|
|
</DIR>
|
|
<H2>n</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX151">n</A>
|
|
<LI><A HREF="gdb.html#IDX389">names of symbols</A>
|
|
<LI><A HREF="gdb.html#IDX363">namespace in C++</A>
|
|
<LI><A HREF="gdb.html#IDX105">negative breakpoint numbers</A>
|
|
<LI><A HREF="gdb.html#IDX73">New <VAR>systag</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX150">next</A>
|
|
<LI><A HREF="gdb.html#IDX157">nexti</A>
|
|
<LI><A HREF="gdb.html#IDX158">ni</A>
|
|
<LI><A HREF="gdb.html#IDX536">Nindy</A>
|
|
<LI><A HREF="gdb.html#IDX629">number representation</A>
|
|
<LI><A HREF="gdb.html#IDX93">numbers for breakpoints</A>
|
|
</DIR>
|
|
<H2>o</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX355">object formats and C++</A>
|
|
<LI><A HREF="gdb.html#IDX20">online documentation</A>
|
|
<LI><A HREF="gdb.html#IDX33">optimized code, debugging</A>
|
|
<LI><A HREF="gdb.html#IDX176">outermost frame</A>
|
|
<LI><A HREF="gdb.html#IDX662">output</A>
|
|
<LI><A HREF="gdb.html#IDX259">output formats</A>
|
|
<LI><A HREF="gdb.html#IDX140">overloading</A>
|
|
<LI><A HREF="gdb.html#IDX371">overloading in C++</A>
|
|
</DIR>
|
|
<H2>p</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX531">packets, reporting on stdout</A>
|
|
<LI><A HREF="gdb.html#IDX405">partial symbol dump</A>
|
|
<LI><A HREF="gdb.html#IDX416">patching binaries</A>
|
|
<LI><A HREF="gdb.html#IDX43">path</A>
|
|
<LI><A HREF="gdb.html#IDX624">pauses in output</A>
|
|
<LI><A HREF="gdb.html#IDX38">pipes</A>
|
|
<LI><A HREF="gdb.html#IDX281">pointer, finding referent</A>
|
|
<LI><A HREF="gdb.html#IDX243">print</A>
|
|
<LI><A HREF="gdb.html#IDX273">print settings</A>
|
|
<LI><A HREF="gdb.html#IDX663">printf</A>
|
|
<LI><A HREF="gdb.html#IDX241">printing data</A>
|
|
<LI><A HREF="gdb.html#IDX62">process image</A>
|
|
<LI><A HREF="gdb.html#IDX85">processes, multiple</A>
|
|
<LI><A HREF="gdb.html#IDX603">prompt</A>
|
|
<LI><A HREF="gdb.html#IDX525">protocol, GDB remote serial</A>
|
|
<LI><A HREF="gdb.html#IDX393">ptype</A>
|
|
<LI><A HREF="gdb.html#IDX511">putDebugChar</A>
|
|
<LI><A HREF="gdb.html#IDX50">pwd</A>
|
|
</DIR>
|
|
<H2>q</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX5">q</A>
|
|
<LI><A HREF="gdb.html#IDX4">quit [<VAR>expression</VAR>]</A>
|
|
<LI><A HREF="gdb.html#IDX18">quotes in commands</A>
|
|
<LI><A HREF="gdb.html#IDX390">quoting names</A>
|
|
</DIR>
|
|
<H2>r</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX117">raise exceptions</A>
|
|
<LI><A HREF="gdb.html#IDX339">range checking</A>
|
|
<LI><A HREF="gdb.html#IDX101">rbreak</A>
|
|
<LI><A HREF="gdb.html#IDX428">reading symbols immediately</A>
|
|
<LI><A HREF="gdb.html#IDX606">readline</A>
|
|
<LI><A HREF="gdb.html#IDX427">readnow</A>
|
|
<LI><A HREF="gdb.html#IDX51">redirection</A>
|
|
<LI><A HREF="gdb.html#IDX677">reference card</A>
|
|
<LI><A HREF="gdb.html#IDX366">reference declarations</A>
|
|
<LI><A HREF="gdb.html#IDX324">register stack, AMD29K</A>
|
|
<LI><A HREF="gdb.html#IDX318">registers</A>
|
|
<LI><A HREF="gdb.html#IDX102">regular expression</A>
|
|
<LI><A HREF="gdb.html#IDX399">reloading symbols</A>
|
|
<LI><A HREF="gdb.html#IDX534">remote connection without stubs</A>
|
|
<LI><A HREF="gdb.html#IDX486">remote debugging</A>
|
|
<LI><A HREF="gdb.html#IDX521">remote programs, interrupting</A>
|
|
<LI><A HREF="gdb.html#IDX517">remote serial debugging summary</A>
|
|
<LI><A HREF="gdb.html#IDX487">remote serial debugging, overview</A>
|
|
<LI><A HREF="gdb.html#IDX527">remote serial protocol</A>
|
|
<LI><A HREF="gdb.html#IDX503">remote serial stub</A>
|
|
<LI><A HREF="gdb.html#IDX488">remote serial stub list</A>
|
|
<LI><A HREF="gdb.html#IDX505">remote serial stub, initialization</A>
|
|
<LI><A HREF="gdb.html#IDX507">remote serial stub, main routine</A>
|
|
<LI><A HREF="gdb.html#IDX523">remote stub, example</A>
|
|
<LI><A HREF="gdb.html#IDX509">remote stub, support routines</A>
|
|
<LI><A HREF="gdb.html#IDX585"><CODE>remotedebug</CODE>, MIPS protocol</A>
|
|
<LI><A HREF="gdb.html#IDX558">remotetimeout</A>
|
|
<LI><A HREF="gdb.html#IDX12">repeating commands</A>
|
|
<LI><A HREF="gdb.html#IDX667">reporting bugs in GDB</A>
|
|
<LI><A HREF="gdb.html#IDX538">reset</A>
|
|
<LI><A HREF="gdb.html#IDX204">response time, MIPS debugging</A>
|
|
<LI><A HREF="gdb.html#IDX144">resuming execution</A>
|
|
<LI><A HREF="gdb.html#IDX13">RET</A>
|
|
<LI><A HREF="gdb.html#IDX588"><CODE>retransmit-timeout</CODE>, MIPS protocol</A>
|
|
<LI><A HREF="gdb.html#IDX413">return</A>
|
|
<LI><A HREF="gdb.html#IDX412">returning from a function</A>
|
|
<LI><A HREF="gdb.html#IDX212">reverse-search</A>
|
|
<LI><A HREF="gdb.html#IDX37">run</A>
|
|
<LI><A HREF="gdb.html#IDX560">Running</A>
|
|
<LI><A HREF="gdb.html#IDX36">running</A>
|
|
<LI><A HREF="gdb.html#IDX543">running 29K programs</A>
|
|
<LI><A HREF="gdb.html#IDX562">running and debugging Sparclet programs</A>
|
|
<LI><A HREF="gdb.html#IDX556">running VxWorks tasks</A>
|
|
<LI><A HREF="gdb.html#IDX110">rwatch</A>
|
|
</DIR>
|
|
<H2>s</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX149">s</A>
|
|
<LI><A HREF="gdb.html#IDX432">saving symbol table</A>
|
|
<LI><A HREF="gdb.html#IDX383">scope</A>
|
|
<LI><A HREF="gdb.html#IDX213">search</A>
|
|
<LI><A HREF="gdb.html#IDX211">searching</A>
|
|
<LI><A HREF="gdb.html#IDX444">section</A>
|
|
<LI><A HREF="gdb.html#IDX182">select-frame</A>
|
|
<LI><A HREF="gdb.html#IDX172">selected frame</A>
|
|
<LI><A HREF="gdb.html#IDX532">serial connections, debugging</A>
|
|
<LI><A HREF="gdb.html#IDX564">serial device, Hitachi micros</A>
|
|
<LI><A HREF="gdb.html#IDX566">serial line speed, Hitachi micros</A>
|
|
<LI><A HREF="gdb.html#IDX518">serial line, <CODE>target remote</CODE></A>
|
|
<LI><A HREF="gdb.html#IDX526">serial protocol, GDB remote</A>
|
|
<LI><A HREF="gdb.html#IDX26">set</A>
|
|
<LI><A HREF="gdb.html#IDX40">set args</A>
|
|
<LI><A HREF="gdb.html#IDX236">set assembly-language</A>
|
|
<LI><A HREF="gdb.html#IDX336">set check</A>, <A HREF="gdb.html#IDX341">set check</A>
|
|
<LI><A HREF="gdb.html#IDX342">set check range</A>
|
|
<LI><A HREF="gdb.html#IDX337">set check type</A>
|
|
<LI><A HREF="gdb.html#IDX637">set complaints</A>
|
|
<LI><A HREF="gdb.html#IDX639">set confirm</A>
|
|
<LI><A HREF="gdb.html#IDX298">set demangle-style</A>
|
|
<LI><A HREF="gdb.html#IDX608">set editing</A>
|
|
<LI><A HREF="gdb.html#IDX484">set endian auto</A>
|
|
<LI><A HREF="gdb.html#IDX482">set endian big</A>
|
|
<LI><A HREF="gdb.html#IDX483">set endian little</A>
|
|
<LI><A HREF="gdb.html#IDX46">set environment</A>
|
|
<LI><A HREF="gdb.html#IDX459">set gnutarget</A>
|
|
<LI><A HREF="gdb.html#IDX625">set height</A>
|
|
<LI><A HREF="gdb.html#IDX620">set history expansion</A>
|
|
<LI><A HREF="gdb.html#IDX613">set history filename</A>
|
|
<LI><A HREF="gdb.html#IDX616">set history save</A>
|
|
<LI><A HREF="gdb.html#IDX618">set history size</A>
|
|
<LI><A HREF="gdb.html#IDX631">set input-radix</A>
|
|
<LI><A HREF="gdb.html#IDX330">set language</A>
|
|
<LI><A HREF="gdb.html#IDX208">set listsize</A>
|
|
<LI><A HREF="gdb.html#IDX568">set machine</A>
|
|
<LI><A HREF="gdb.html#IDX570">set memory <VAR>mod</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX579">set mipsfpu</A>
|
|
<LI><A HREF="gdb.html#IDX632">set output-radix</A>
|
|
<LI><A HREF="gdb.html#IDX274">set print address</A>
|
|
<LI><A HREF="gdb.html#IDX282">set print array</A>
|
|
<LI><A HREF="gdb.html#IDX296">set print asm-demangle</A>
|
|
<LI><A HREF="gdb.html#IDX294">set print demangle</A>
|
|
<LI><A HREF="gdb.html#IDX284">set print elements</A>
|
|
<LI><A HREF="gdb.html#IDX278">set print max-symbolic-offset</A>
|
|
<LI><A HREF="gdb.html#IDX286">set print null-stop</A>
|
|
<LI><A HREF="gdb.html#IDX302">set print object</A>
|
|
<LI><A HREF="gdb.html#IDX287">set print pretty</A>
|
|
<LI><A HREF="gdb.html#IDX289">set print sevenbit-strings</A>
|
|
<LI><A HREF="gdb.html#IDX304">set print static-members</A>
|
|
<LI><A HREF="gdb.html#IDX276">set print symbol-filename</A>
|
|
<LI><A HREF="gdb.html#IDX291">set print union</A>
|
|
<LI><A HREF="gdb.html#IDX306">set print vtbl</A>
|
|
<LI><A HREF="gdb.html#IDX577">set processor <VAR>args</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX604">set prompt</A>
|
|
<LI><A HREF="gdb.html#IDX529">set remotedebug</A>, <A HREF="gdb.html#IDX583">set remotedebug</A>
|
|
<LI><A HREF="gdb.html#IDX591">set retransmit-timeout</A>
|
|
<LI><A HREF="gdb.html#IDX322">set rstack_high_address</A>
|
|
<LI><A HREF="gdb.html#IDX400">set symbol-reloading</A>
|
|
<LI><A HREF="gdb.html#IDX589">set timeout</A>
|
|
<LI><A HREF="gdb.html#IDX408">set variable</A>
|
|
<LI><A HREF="gdb.html#IDX635">set verbose</A>
|
|
<LI><A HREF="gdb.html#IDX626">set width</A>
|
|
<LI><A HREF="gdb.html#IDX419">set write</A>
|
|
<LI><A HREF="gdb.html#IDX504">set_debug_traps</A>
|
|
<LI><A HREF="gdb.html#IDX407">setting variables</A>
|
|
<LI><A HREF="gdb.html#IDX108">setting watchpoints</A>
|
|
<LI><A HREF="gdb.html#IDX497">SH</A>
|
|
<LI><A HREF="gdb.html#IDX495">sh-stub.c</A>
|
|
<LI><A HREF="gdb.html#IDX451">share</A>
|
|
<LI><A HREF="gdb.html#IDX447">shared libraries</A>
|
|
<LI><A HREF="gdb.html#IDX450">sharedlibrary</A>
|
|
<LI><A HREF="gdb.html#IDX7">shell</A>
|
|
<LI><A HREF="gdb.html#IDX8">shell escape</A>
|
|
<LI><A HREF="gdb.html#IDX27">show</A>
|
|
<LI><A HREF="gdb.html#IDX41">show args</A>
|
|
<LI><A HREF="gdb.html#IDX343">show check range</A>
|
|
<LI><A HREF="gdb.html#IDX338">show check type</A>
|
|
<LI><A HREF="gdb.html#IDX622">show commands</A>
|
|
<LI><A HREF="gdb.html#IDX638">show complaints</A>
|
|
<LI><A HREF="gdb.html#IDX643">show confirm</A>
|
|
<LI><A HREF="gdb.html#IDX314">show convenience</A>
|
|
<LI><A HREF="gdb.html#IDX31">show copying</A>
|
|
<LI><A HREF="gdb.html#IDX301">show demangle-style</A>
|
|
<LI><A HREF="gdb.html#IDX228">show directories</A>
|
|
<LI><A HREF="gdb.html#IDX610">show editing</A>
|
|
<LI><A HREF="gdb.html#IDX485">show endian</A>
|
|
<LI><A HREF="gdb.html#IDX45">show environment</A>
|
|
<LI><A HREF="gdb.html#IDX460">show gnutarget</A>
|
|
<LI><A HREF="gdb.html#IDX628">show height</A>
|
|
<LI><A HREF="gdb.html#IDX621">show history</A>
|
|
<LI><A HREF="gdb.html#IDX633">show input-radix</A>
|
|
<LI><A HREF="gdb.html#IDX331">show language</A>
|
|
<LI><A HREF="gdb.html#IDX209">show listsize</A>
|
|
<LI><A HREF="gdb.html#IDX569">show machine</A>
|
|
<LI><A HREF="gdb.html#IDX580">show mipsfpu</A>
|
|
<LI><A HREF="gdb.html#IDX634">show output-radix</A>
|
|
<LI><A HREF="gdb.html#IDX44">show paths</A>
|
|
<LI><A HREF="gdb.html#IDX275">show print address</A>
|
|
<LI><A HREF="gdb.html#IDX283">show print array</A>
|
|
<LI><A HREF="gdb.html#IDX297">show print asm-demangle</A>
|
|
<LI><A HREF="gdb.html#IDX295">show print demangle</A>
|
|
<LI><A HREF="gdb.html#IDX285">show print elements</A>
|
|
<LI><A HREF="gdb.html#IDX279">show print max-symbolic-offset</A>
|
|
<LI><A HREF="gdb.html#IDX303">show print object</A>
|
|
<LI><A HREF="gdb.html#IDX288">show print pretty</A>
|
|
<LI><A HREF="gdb.html#IDX290">show print sevenbit-strings</A>
|
|
<LI><A HREF="gdb.html#IDX305">show print static-members</A>
|
|
<LI><A HREF="gdb.html#IDX277">show print symbol-filename</A>
|
|
<LI><A HREF="gdb.html#IDX292">show print union</A>
|
|
<LI><A HREF="gdb.html#IDX307">show print vtbl</A>
|
|
<LI><A HREF="gdb.html#IDX578">show processor</A>
|
|
<LI><A HREF="gdb.html#IDX605">show prompt</A>
|
|
<LI><A HREF="gdb.html#IDX530">show remotedebug</A>, <A HREF="gdb.html#IDX584">show remotedebug</A>
|
|
<LI><A HREF="gdb.html#IDX592">show retransmit-timeout</A>
|
|
<LI><A HREF="gdb.html#IDX325">show rstack_high_address</A>
|
|
<LI><A HREF="gdb.html#IDX401">show symbol-reloading</A>
|
|
<LI><A HREF="gdb.html#IDX590">show timeout</A>
|
|
<LI><A HREF="gdb.html#IDX651">show user</A>
|
|
<LI><A HREF="gdb.html#IDX312">show values</A>
|
|
<LI><A HREF="gdb.html#IDX636">show verbose</A>
|
|
<LI><A HREF="gdb.html#IDX29">show version</A>
|
|
<LI><A HREF="gdb.html#IDX32">show warranty</A>
|
|
<LI><A HREF="gdb.html#IDX627">show width</A>
|
|
<LI><A HREF="gdb.html#IDX420">show write</A>
|
|
<LI><A HREF="gdb.html#IDX156">si</A>
|
|
<LI><A HREF="gdb.html#IDX411">signal</A>
|
|
<LI><A HREF="gdb.html#IDX159">signals</A>
|
|
<LI><A HREF="gdb.html#IDX139">silent</A>
|
|
<LI><A HREF="gdb.html#IDX601">sim</A>
|
|
<LI><A HREF="gdb.html#IDX593">simulator</A>
|
|
<LI><A HREF="gdb.html#IDX596">simulator, H8/300 or H8/500</A>
|
|
<LI><A HREF="gdb.html#IDX598">simulator, Hitachi SH</A>
|
|
<LI><A HREF="gdb.html#IDX594">simulator, Z8000</A>
|
|
<LI><A HREF="gdb.html#IDX623">size of screen</A>
|
|
<LI><A HREF="gdb.html#IDX660">source</A>
|
|
<LI><A HREF="gdb.html#IDX215">source path</A>
|
|
<LI><A HREF="gdb.html#IDX499">Sparc</A>
|
|
<LI><A HREF="gdb.html#IDX498">sparc-stub.c</A>
|
|
<LI><A HREF="gdb.html#IDX500">sparcl-stub.c</A>
|
|
<LI><A HREF="gdb.html#IDX557">Sparclet</A>
|
|
<LI><A HREF="gdb.html#IDX502">SparcLite</A>
|
|
<LI><A HREF="gdb.html#IDX565">speed</A>
|
|
<LI><A HREF="gdb.html#IDX547">ST2000 auxiliary commands</A>
|
|
<LI><A HREF="gdb.html#IDX548">st2000 <VAR>cmd</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX174">stack frame</A>
|
|
<LI><A HREF="gdb.html#IDX202">stack on MIPS</A>
|
|
<LI><A HREF="gdb.html#IDX455">stacking targets</A>
|
|
<LI><A HREF="gdb.html#IDX35">starting</A>
|
|
<LI><A HREF="gdb.html#IDX549">STDBUG commands (ST2000)</A>
|
|
<LI><A HREF="gdb.html#IDX148">step</A>
|
|
<LI><A HREF="gdb.html#IDX155">stepi</A>
|
|
<LI><A HREF="gdb.html#IDX142">stepping</A>
|
|
<LI><A HREF="gdb.html#IDX167">stopped threads</A>
|
|
<LI><A HREF="gdb.html#IDX524">stub example, remote debugging</A>
|
|
<LI><A HREF="gdb.html#IDX642">stupid questions</A>
|
|
<LI><A HREF="gdb.html#IDX70">switching threads</A>
|
|
<LI><A HREF="gdb.html#IDX81">switching threads automatically</A>
|
|
<LI><A HREF="gdb.html#IDX300">symbol decoding style, C++</A>
|
|
<LI><A HREF="gdb.html#IDX403">symbol dump</A>
|
|
<LI><A HREF="gdb.html#IDX388">symbol names</A>
|
|
<LI><A HREF="gdb.html#IDX141">symbol overloading</A>
|
|
<LI><A HREF="gdb.html#IDX421">symbol table</A>
|
|
<LI><A HREF="gdb.html#IDX426">symbol-file</A>
|
|
<LI><A HREF="gdb.html#IDX429">symbols, reading immediately</A>
|
|
</DIR>
|
|
<H2>t</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX454">target</A>
|
|
<LI><A HREF="gdb.html#IDX466">target amd-eb</A>
|
|
<LI><A HREF="gdb.html#IDX478">target array</A>
|
|
<LI><A HREF="gdb.html#IDX472">target bug</A>
|
|
<LI><A HREF="gdb.html#IDX481">target byte order</A>
|
|
<LI><A HREF="gdb.html#IDX462">target core</A>
|
|
<LI><A HREF="gdb.html#IDX473">target cpu32bug</A>
|
|
<LI><A HREF="gdb.html#IDX575">target ddb <VAR>port</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX567">target e7000</A>
|
|
<LI><A HREF="gdb.html#IDX476">target est</A>
|
|
<LI><A HREF="gdb.html#IDX461">target exec</A>
|
|
<LI><A HREF="gdb.html#IDX468">target hms</A>
|
|
<LI><A HREF="gdb.html#IDX576">target lsi <VAR>port</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX573">target mips <VAR>port</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX469">target nindy</A>
|
|
<LI><A HREF="gdb.html#IDX474">target op50n</A>
|
|
<LI><A HREF="gdb.html#IDX574">target pmon <VAR>port</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX463">target remote</A>
|
|
<LI><A HREF="gdb.html#IDX477">target rom68k</A>
|
|
<LI><A HREF="gdb.html#IDX464">target sim</A>, <A HREF="gdb.html#IDX602">target sim</A>
|
|
<LI><A HREF="gdb.html#IDX479">target sparclite</A>
|
|
<LI><A HREF="gdb.html#IDX470">target st2000</A>
|
|
<LI><A HREF="gdb.html#IDX465">target udi</A>
|
|
<LI><A HREF="gdb.html#IDX471">target vxworks</A>
|
|
<LI><A HREF="gdb.html#IDX475">target w89k</A>
|
|
<LI><A HREF="gdb.html#IDX98">tbreak</A>
|
|
<LI><A HREF="gdb.html#IDX519">TCP port, <CODE>target remote</CODE></A>
|
|
<LI><A HREF="gdb.html#IDX53">terminal</A>
|
|
<LI><A HREF="gdb.html#IDX100">thbreak</A>
|
|
<LI><A HREF="gdb.html#IDX362">this</A>
|
|
<LI><A HREF="gdb.html#IDX79">thread apply</A>
|
|
<LI><A HREF="gdb.html#IDX165">thread breakpoints</A>
|
|
<LI><A HREF="gdb.html#IDX76">thread identifier (GDB)</A>
|
|
<LI><A HREF="gdb.html#IDX74">thread identifier (system)</A>
|
|
<LI><A HREF="gdb.html#IDX75">thread number</A>
|
|
<LI><A HREF="gdb.html#IDX78">thread <VAR>threadno</VAR></A>
|
|
<LI><A HREF="gdb.html#IDX114">threads and watchpoints</A>
|
|
<LI><A HREF="gdb.html#IDX68">threads of execution</A>
|
|
<LI><A HREF="gdb.html#IDX82">threads, automatic switching</A>
|
|
<LI><A HREF="gdb.html#IDX170">threads, continuing</A>
|
|
<LI><A HREF="gdb.html#IDX168">threads, stopped</A>
|
|
<LI><A HREF="gdb.html#IDX587"><CODE>timeout</CODE>, MIPS protocol</A>
|
|
<LI><A HREF="gdb.html#IDX55">tty</A>
|
|
<LI><A HREF="gdb.html#IDX247">type casting memory</A>
|
|
<LI><A HREF="gdb.html#IDX334">type checking</A>
|
|
<LI><A HREF="gdb.html#IDX365">type conversions in C++</A>
|
|
</DIR>
|
|
<H2>u</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX154">u</A>
|
|
<LI><A HREF="gdb.html#IDX539">UDI</A>
|
|
<LI><A HREF="gdb.html#IDX541">udi</A>
|
|
<LI><A HREF="gdb.html#IDX268">undisplay</A>
|
|
<LI><A HREF="gdb.html#IDX260">unknown address, locating</A>
|
|
<LI><A HREF="gdb.html#IDX47">unset environment</A>
|
|
<LI><A HREF="gdb.html#IDX153">until</A>
|
|
<LI><A HREF="gdb.html#IDX190">up</A>
|
|
<LI><A HREF="gdb.html#IDX194">up-silently</A>
|
|
<LI><A HREF="gdb.html#IDX644">user-defined command</A>
|
|
</DIR>
|
|
<H2>v</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX308">value history</A>
|
|
<LI><A HREF="gdb.html#IDX250">variable name conflict</A>
|
|
<LI><A HREF="gdb.html#IDX255">variable values, wrong</A>
|
|
<LI><A HREF="gdb.html#IDX409">variables, setting</A>
|
|
<LI><A HREF="gdb.html#IDX30">version number</A>
|
|
<LI><A HREF="gdb.html#IDX552">VxWorks</A>
|
|
<LI><A HREF="gdb.html#IDX553">vxworks-timeout</A>
|
|
</DIR>
|
|
<H2>w</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX109">watch</A>
|
|
<LI><A HREF="gdb.html#IDX88">watchpoints</A>
|
|
<LI><A HREF="gdb.html#IDX113">watchpoints and threads</A>
|
|
<LI><A HREF="gdb.html#IDX392">whatis</A>
|
|
<LI><A HREF="gdb.html#IDX185">where</A>
|
|
<LI><A HREF="gdb.html#IDX648">while</A>
|
|
<LI><A HREF="gdb.html#IDX280">wild pointer, interpreting</A>
|
|
<LI><A HREF="gdb.html#IDX17">word completion</A>
|
|
<LI><A HREF="gdb.html#IDX225">working directory</A>
|
|
<LI><A HREF="gdb.html#IDX48">working directory (of your program)</A>
|
|
<LI><A HREF="gdb.html#IDX329">working language</A>
|
|
<LI><A HREF="gdb.html#IDX418">writing into corefiles</A>
|
|
<LI><A HREF="gdb.html#IDX417">writing into executables</A>
|
|
<LI><A HREF="gdb.html#IDX254">wrong values</A>
|
|
</DIR>
|
|
<H2>x</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX262">x</A>
|
|
<LI><A HREF="gdb.html#IDX358">XCOFF and C++</A>
|
|
</DIR>
|
|
<H2>z</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX595">Z8000 simulator</A>
|
|
</DIR>
|
|
<H2>{</H2>
|
|
<DIR>
|
|
<LI><A HREF="gdb.html#IDX246">{<VAR>type</VAR>}</A>
|
|
</DIR>
|
|
|
|
</P>
|
|
|
|
<P><HR><P>
|
|
This document was generated on 23 April 1998 using the
|
|
<A HREF="http://wwwcn.cern.ch/dci/texi2html/">texi2html</A>
|
|
translator version 1.51.</P>
|
|
</BODY>
|
|
</HTML>
|