gdb.html

vxworks相关论文

</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="SEC23" HREF="gdb_toc.html#TOC23">Debugging an already-running process</A></H2>
<P>
<A NAME="IDX56"></A>
<A NAME="IDX57"></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#SEC86">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="IDX58"></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#SEC99">Optional warnings and messages</A>).

</P>


<H2><A NAME="SEC24" HREF="gdb_toc.html#TOC24">Killing the child process</A></H2>

<DL COMPACT>

<DT><CODE>kill</CODE>
<DD>
<A NAME="IDX59"></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="SEC25" HREF="gdb_toc.html#TOC25">Additional process information</A></H2>

<P>
<A NAME="IDX60"></A>
<A NAME="IDX61"></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="IDX62"></A>
 
Summarize available information about the process.

<A NAME="IDX63"></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="IDX64"></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="IDX65"></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="IDX66"></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="SEC26" HREF="gdb_toc.html#TOC26">Debugging programs with multiple threads</A></H2>

<P>
<A NAME="IDX67"></A>
<A NAME="IDX68"></A>
<A NAME="IDX69"></A>
In some operating systems, a single program may have more than one
<EM>thread</EM> 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="IDX70"></A>
<A NAME="IDX71"></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 <EM>current thread</EM>.  Debugging commands show
program information from the perspective of the current thread.

</P>
<P>
<A NAME="IDX72"></A>
<A NAME="IDX73"></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="IDX74"></A>
<A NAME="IDX75"></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="IDX76"></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="IDX77"></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="IDX78"></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="IDX79"></A>
<A NAME="IDX80"></A>
<A NAME="IDX81"></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#SEC40">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#SEC31">Setting watchpoints</A>, for information about
watchpoints in programs with multiple threads.

</P>


<H2><A NAME="SEC27" HREF="gdb_toc.html#TOC27">Debugging programs with multiple processes</A></H2>

<P>
<A NAME="IDX82"></A>
<A NAME="IDX83"></A>
<A NAME="IDX84"></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#SEC23">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="SEC28" HREF="gdb_toc.html#TOC28">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="IDX85"></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="SEC29" HREF="gdb_toc.html#TOC29">Breakpoints, watchpoints, and exceptions</A></H2>

<P>
<A NAME="IDX86"></A>
A <EM>breakpoint</EM> 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#SEC30">Setting breakpoints</A>), to specify the place where
your program should stop by line number, func