gdb.html

vxworks相关论文

 : 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 "&#60;QUOTE&#62;", rq=0x34c88 "&#60;UNQUOTE&#62;")
    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 "&#60;QUOTE&#62;", rq=0x34c88 "&#60;UNQUOTE&#62;")
    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 "&#60;QUOTE&#62;"
(gdb) <B>p rquote</B>
$2 = 0x35d50 "&#60;UNQUOTE&#62;"
</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(&#60;QUOTE&#62;foo&#60;UNQUOTE&#62;))</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="SEC6" HREF="gdb_toc.html#TOC6">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="SEC7" HREF="gdb_toc.html#TOC7">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="SEC8" HREF="gdb_toc.html#TOC8">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#SEC103">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#SEC86">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="SEC9" HREF="gdb_toc.html#TOC9">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#SEC103">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