gdb.html

vxworks相关论文

<CODE>help info</CODE>.

<A NAME="IDX25"></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="IDX26"></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="IDX27"></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="IDX28"></A>
 <A NAME="IDX29"></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="IDX30"></A>
<DT><CODE>show copying</CODE>
<DD>
Display information about permission for copying GDB.

<A NAME="IDX31"></A>
<DT><CODE>show warranty</CODE>
<DD>
Display the GNU "NO WARRANTY" statement.
</DL>



<H1><A NAME="SEC16" HREF="gdb_toc.html#TOC16">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="SEC17" HREF="gdb_toc.html#TOC17">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="IDX32"></A>
<A NAME="IDX33"></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="SEC18" HREF="gdb_toc.html#TOC18">Starting your program</A></H2>
<P>
<A NAME="IDX34"></A>
<A NAME="IDX35"></A>

</P>
<DL COMPACT>

<DT><CODE>run</CODE>
<DD>
<A NAME="IDX36"></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#SEC6">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#SEC86">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#SEC19">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#SEC20">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#SEC21">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#SEC22">Your program's input and output</A>.

<A NAME="IDX37"></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#SEC28">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#SEC52">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="SEC19" HREF="gdb_toc.html#TOC19">Your program's arguments</A></H2>

<P>
<A NAME="IDX38"></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="IDX39"></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="IDX40"></A>
<DT><CODE>show args</CODE>
<DD>
Show the arguments to give your program when it is started.
</DL>



<H2><A NAME="SEC20" HREF="gdb_toc.html#TOC20">Your program's environment</A></H2>

<P>
<A NAME="IDX41"></A>
The <EM>environment</EM> 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="IDX42"></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="IDX43"></A>
<DT><CODE>show paths</CODE>
<DD>
Display the list of search paths for executables (the <CODE>PATH</CODE>
environment variable).

<A NAME="IDX44"></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="IDX45"></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="IDX46"></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="SEC21" HREF="gdb_toc.html#TOC21">Your program's working directory</A></H2>

<P>
<A NAME="IDX47"></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#SEC86">Commands to specify files</A>.

</P>
<DL COMPACT>

<DT><CODE>cd <VAR>directory</VAR></CODE>
<DD>
<A NAME="IDX48"></A>
 
Set the GDB working directory to <VAR>directory</VAR>.

<A NAME="IDX49"></A>
<DT><CODE>pwd</CODE>
<DD>
Print the GDB working directory.
</DL>



<H2><A NAME="SEC22" HREF="gdb_toc.html#TOC22">Your program's input and output</A></H2>

<P>
<A NAME="IDX50"></A>
<A NAME="IDX51"></A>
<A NAME="IDX52"></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="IDX53"></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 &#62; outfile
</PRE>

<P>
starts your program, diverting its output to the file <TT>`outfile'</TT>.

</P>
<P>
<A NAME="IDX54"></A>
<A NAME="IDX55"></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.