372 lines
18 KiB
HTML
372 lines
18 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on October, 26 2002 by texi2html 1.64 -->
|
|
<!--
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
Karl Berry <karl@freefriends.org>
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
and many others.
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
|
|
|
-->
|
|
<HEAD>
|
|
<TITLE>GDB Internals: Hints</TITLE>
|
|
|
|
<META NAME="description" CONTENT="GDB Internals: Hints">
|
|
<META NAME="keywords" CONTENT="GDB Internals: Hints">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
|
|
|
</HEAD>
|
|
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
|
|
|
<A NAME="SEC179"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_16.html#SEC178"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC180"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_2.html#SEC2"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_18.html#SEC184"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H1> 17. Hints </H1>
|
|
<!--docid::SEC179::-->
|
|
<P>
|
|
|
|
Check the <TT>`README'</TT> file, it often has useful information that does not
|
|
appear anywhere else in the directory.
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gdbint_17.html#SEC180">17.1 Getting Started</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Getting started working on GDB</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gdbint_17.html#SEC181">17.2 Debugging GDB with itself</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Getting Started"></A>
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC180"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC179"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC181"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC179"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC179"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_18.html#SEC184"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 17.1 Getting Started </H2>
|
|
<!--docid::SEC180::-->
|
|
<P>
|
|
|
|
GDB is a large and complicated program, and if you first starting to
|
|
work on it, it can be hard to know where to start. Fortunately, if you
|
|
know how to go about it, there are ways to figure out what is going on.
|
|
</P><P>
|
|
|
|
This manual, the GDB Internals manual, has information which applies
|
|
generally to many parts of GDB.
|
|
</P><P>
|
|
|
|
Information about particular functions or data structures are located in
|
|
comments with those functions or data structures. If you run across a
|
|
function or a global variable which does not have a comment correctly
|
|
explaining what is does, this can be thought of as a bug in GDB; feel
|
|
free to submit a bug report, with a suggested comment if you can figure
|
|
out what the comment should say. If you find a comment which is
|
|
actually wrong, be especially sure to report that.
|
|
</P><P>
|
|
|
|
Comments explaining the function of macros defined in host, target, or
|
|
native dependent files can be in several places. Sometimes they are
|
|
repeated every place the macro is defined. Sometimes they are where the
|
|
macro is used. Sometimes there is a header file which supplies a
|
|
default definition of the macro, and the comment is there. This manual
|
|
also documents all the available macros.
|
|
</P><P>
|
|
|
|
Start with the header files. Once you have some idea of how
|
|
GDB's internal symbol tables are stored (see <TT>`symtab.h'</TT>,
|
|
<TT>`gdbtypes.h'</TT>), you will find it much easier to understand the
|
|
code which uses and creates those symbol tables.
|
|
</P><P>
|
|
|
|
You may wish to process the information you are getting somehow, to
|
|
enhance your understanding of it. Summarize it, translate it to another
|
|
language, add some (perhaps trivial or non-useful) feature to GDB, use
|
|
the code to predict what a test case would do and write the test case
|
|
and verify your prediction, etc. If you are reading code and your eyes
|
|
are starting to glaze over, this is a sign you need to use a more active
|
|
approach.
|
|
</P><P>
|
|
|
|
Once you have a part of GDB to start with, you can find more
|
|
specifically the part you are looking for by stepping through each
|
|
function with the <CODE>next</CODE> command. Do not use <CODE>step</CODE> or you
|
|
will quickly get distracted; when the function you are stepping through
|
|
calls another function try only to get a big-picture understanding
|
|
(perhaps using the comment at the beginning of the function being
|
|
called) of what it does. This way you can identify which of the
|
|
functions being called by the function you are stepping through is the
|
|
one which you are interested in. You may need to examine the data
|
|
structures generated at each stage, with reference to the comments in
|
|
the header files explaining what the data structures are supposed to
|
|
look like.
|
|
</P><P>
|
|
|
|
Of course, this same technique can be used if you are just reading the
|
|
code, rather than actually stepping through it. The same general
|
|
principle applies--when the code you are looking at calls something
|
|
else, just try to understand generally what the code being called does,
|
|
rather than worrying about all its details.
|
|
</P><P>
|
|
|
|
<A NAME="IDX524"></A>
|
|
A good place to start when tracking down some particular area is with
|
|
a command which invokes that feature. Suppose you want to know how
|
|
single-stepping works. As a GDB user, you know that the
|
|
<CODE>step</CODE> command invokes single-stepping. The command is invoked
|
|
via command tables (see <TT>`command.h'</TT>); by convention the function
|
|
which actually performs the command is formed by taking the name of
|
|
the command and adding <SAMP>`_command'</SAMP>, or in the case of an
|
|
<CODE>info</CODE> subcommand, <SAMP>`_info'</SAMP>. For example, the <CODE>step</CODE>
|
|
command invokes the <CODE>step_command</CODE> function and the <CODE>info
|
|
display</CODE> command invokes <CODE>display_info</CODE>. When this convention is
|
|
not followed, you might have to use <CODE>grep</CODE> or <KBD>M-x
|
|
tags-search</KBD> in emacs, or run GDB on itself and set a
|
|
breakpoint in <CODE>execute_command</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX525"></A>
|
|
If all of the above fail, it may be appropriate to ask for information
|
|
on <CODE>bug-gdb</CODE>. But <EM>never</EM> post a generic question like "I was
|
|
wondering if anyone could give me some tips about understanding
|
|
GDB"---if we had some magic secret we would put it in this manual.
|
|
Suggestions for improving the manual are always welcome, of course.
|
|
</P><P>
|
|
|
|
<A NAME="Debugging GDB"></A>
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC181"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC180"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC182"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC182"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC179"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_18.html#SEC184"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 17.2 Debugging GDB with itself </H2>
|
|
<!--docid::SEC181::-->
|
|
<P>
|
|
|
|
If GDB is limping on your machine, this is the preferred way to get it
|
|
fully functional. Be warned that in some ancient Unix systems, like
|
|
Ultrix 4.2, a program can't be running in one process while it is being
|
|
debugged in another. Rather than typing the command <KBD>./gdb
|
|
./gdb</KBD>, which works on Suns and such, you can copy <TT>`gdb'</TT> to
|
|
<TT>`gdb2'</TT> and then type <KBD>./gdb ./gdb2</KBD>.
|
|
</P><P>
|
|
|
|
When you run GDB in the GDB source directory, it will read a
|
|
<TT>`.gdbinit'</TT> file that sets up some simple things to make debugging
|
|
gdb easier. The <CODE>info</CODE> command, when executed without a subcommand
|
|
in a GDB being debugged by gdb, will pop you back up to the top level
|
|
gdb. See <TT>`.gdbinit'</TT> for details.
|
|
</P><P>
|
|
|
|
If you use emacs, you will probably want to do a <CODE>make TAGS</CODE> after
|
|
you configure your distribution; this will put the machine dependent
|
|
routines for your local machine where they will be accessed first by
|
|
<KBD>M-.</KBD>
|
|
</P><P>
|
|
|
|
Also, make sure that you've either compiled GDB with your local cc, or
|
|
have run <CODE>fixincludes</CODE> if you are compiling with gcc.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC182"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC181"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC183"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC183"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC179"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_18.html#SEC184"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 17.3 Submitting Patches </H2>
|
|
<!--docid::SEC182::-->
|
|
<P>
|
|
|
|
<A NAME="IDX526"></A>
|
|
Thanks for thinking of offering your changes back to the community of
|
|
GDB users. In general we like to get well designed enhancements.
|
|
Thanks also for checking in advance about the best way to transfer the
|
|
changes.
|
|
</P><P>
|
|
|
|
The GDB maintainers will only install "cleanly designed" patches.
|
|
This manual summarizes what we believe to be clean design for GDB.
|
|
</P><P>
|
|
|
|
If the maintainers don't have time to put the patch in when it arrives,
|
|
or if there is any question about a patch, it goes into a large queue
|
|
with everyone else's patches and bug reports.
|
|
</P><P>
|
|
|
|
<A NAME="IDX527"></A>
|
|
The legal issue is that to incorporate substantial changes requires a
|
|
copyright assignment from you and/or your employer, granting ownership
|
|
of the changes to the Free Software Foundation. You can get the
|
|
standard documents for doing this by sending mail to <CODE>gnu@gnu.org</CODE>
|
|
and asking for it. We recommend that people write in "All programs
|
|
owned by the Free Software Foundation" as "NAME OF PROGRAM", so that
|
|
changes in many programs (not just GDB, but GAS, Emacs, GCC,
|
|
etc) can be
|
|
contributed with only one piece of legalese pushed through the
|
|
bureaucracy and filed with the FSF. We can't start merging changes until
|
|
this paperwork is received by the FSF (their rules, which we follow
|
|
since we maintain it for them).
|
|
</P><P>
|
|
|
|
Technically, the easiest way to receive changes is to receive each
|
|
feature as a small context diff or unidiff, suitable for <CODE>patch</CODE>.
|
|
Each message sent to me should include the changes to C code and
|
|
header files for a single feature, plus <TT>`ChangeLog'</TT> entries for
|
|
each directory where files were modified, and diffs for any changes
|
|
needed to the manuals (<TT>`gdb/doc/gdb.texinfo'</TT> or
|
|
<TT>`gdb/doc/gdbint.texinfo'</TT>). If there are a lot of changes for a
|
|
single feature, they can be split down into multiple messages.
|
|
</P><P>
|
|
|
|
In this way, if we read and like the feature, we can add it to the
|
|
sources with a single patch command, do some testing, and check it in.
|
|
If you leave out the <TT>`ChangeLog'</TT>, we have to write one. If you leave
|
|
out the doc, we have to puzzle out what needs documenting. Etc., etc.
|
|
</P><P>
|
|
|
|
The reason to send each change in a separate message is that we will not
|
|
install some of the changes. They'll be returned to you with questions
|
|
or comments. If we're doing our job correctly, the message back to you
|
|
will say what you have to fix in order to make the change acceptable.
|
|
The reason to have separate messages for separate features is so that
|
|
the acceptable changes can be installed while one or more changes are
|
|
being reworked. If multiple features are sent in a single message, we
|
|
tend to not put in the effort to sort out the acceptable changes from
|
|
the unacceptable, so none of the features get installed until all are
|
|
acceptable.
|
|
</P><P>
|
|
|
|
If this sounds painful or authoritarian, well, it is. But we get a lot
|
|
of bug reports and a lot of patches, and many of them don't get
|
|
installed because we don't have the time to finish the job that the bug
|
|
reporter or the contributor could have done. Patches that arrive
|
|
complete, working, and well designed, tend to get installed on the day
|
|
they arrive. The others go into a queue and get installed as time
|
|
permits, which, since the maintainers have many demands to meet, may not
|
|
be for quite some time.
|
|
</P><P>
|
|
|
|
Please send patches directly to
|
|
<A HREF="mailto:gdb-patches@sources.redhat.com">the GDB maintainers</A>.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC183"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC182"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_18.html#SEC184"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC179"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC179"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_18.html#SEC184"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 17.4 Obsolete Conditionals </H2>
|
|
<!--docid::SEC183::-->
|
|
<P>
|
|
|
|
Fragments of old code in GDB sometimes reference or set the following
|
|
configuration macros. They should not be used by new code, and old uses
|
|
should be removed as those parts of the debugger are otherwise touched.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>STACK_END_ADDR</CODE>
|
|
<DD>This macro used to define where the end of the stack appeared, for use
|
|
in interpreting core file formats that don't record this address in the
|
|
core file itself. This information is now configured in BFD, and GDB
|
|
gets the info portably from there. The values in GDB's configuration
|
|
files should be moved into BFD configuration files (if needed there),
|
|
and deleted from all of GDB's config files.
|
|
<P>
|
|
|
|
Any <TT>`<VAR>foo</VAR>-xdep.c'</TT> file that references STACK_END_ADDR
|
|
is so old that it has never been converted to use BFD. Now that's old!
|
|
</P><P>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="GNU Free Documentation License"></A>
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_17.html#SEC179"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_18.html#SEC184"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<BR>
|
|
<FONT SIZE="-1">
|
|
|
|
<address>
|
|
|
|
<p>Please send FSF & GNU inquiries & questions to <a
|
|
href="mailto:gnu@gnu.org">gnu@gnu.org</a>. There are also <a
|
|
href="http://www.gnu.org/home.html#ContactInfo">other ways to
|
|
contact</a> the FSF.</p>
|
|
|
|
<p>These pages are maintained by <a
|
|
href="http://www.gnu.org/software/gdb/">the GDB developers</a>.</p>
|
|
|
|
<p>Copyright Free Software Foundation, Inc., 59 Temple Place - Suite
|
|
330, Boston, MA 02111, USA.</p>
|
|
|
|
<p>Verbatim copying and distribution of this entire article is
|
|
permitted in any medium, provided this notice is preserved.</p>
|
|
|
|
</address>
|
|
|
|
This document was generated
|
|
by <I>GDB Administrator</I> on <I>October, 26 2002</I>
|
|
using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
|
|
"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|