246 lines
10 KiB
Plaintext
246 lines
10 KiB
Plaintext
GDB SNAPSHOT SYSTEM
|
|
(general info)
|
|
Updated 8/23/93
|
|
|
|
WHAT ARE GDB SNAPSHOTS
|
|
----------------------
|
|
|
|
Snapshots are an "image" of the main GDB development tree, captured at a
|
|
particular random instant in time. When you use the snapshots, you should be
|
|
able to maintain a local copy of GDB that is no more than one day older than
|
|
the official source tree used by the GDB maintainers.
|
|
|
|
The primary purpose of providing snapshots is to widen the group of motivated
|
|
developers that would like to help test, debug, and enhance GDB, by providing
|
|
you with access to the "latest and greatest" source. This has several
|
|
advantages, and several disadvantages.
|
|
|
|
First the advantages:
|
|
|
|
o Once we have a large base of motivated testers using the snapshots,
|
|
this should provide good coverage across all currently supported
|
|
GDB hosts and targets. If a new bug is introduced in GDB due to
|
|
fixing another bug or ongoing development, it should become
|
|
obvious much more quickly and get fixed before the next general
|
|
net release. This should help to reduce the chances of GDB being
|
|
released to the general public with a major bug that went unnoticed
|
|
during the release cycle testing because they are machine dependent.
|
|
We hope to greatly improve GDB's stability and reliability by
|
|
involving more people and more execution environments in the
|
|
prerelease testing.
|
|
|
|
o With access to the latest source, any diffs that you send to fix
|
|
bugs or add new features should be much easier for the GDB team
|
|
to merge into the official source base (after suitable review
|
|
of course). This encourages us to merge your changes quicker,
|
|
while they are still "fresh".
|
|
|
|
o Once your diffs are merged, you can obtain a new copy of GDB
|
|
containing your changes almost immediately. Thus you do not
|
|
have to maintain local copies of your changes for any longer
|
|
than it takes to get them merged into the official source base.
|
|
This encourages you to send in changes quicker.
|
|
|
|
And the disadvantages:
|
|
|
|
o The snapshot you get will be largely untested and of unknown quality.
|
|
It may fail to configure or compile. It may have serious bugs.
|
|
You should always keep a copy of the last known working version
|
|
before updating to the current snapshot, or at least be able to
|
|
regenerate a working version if the latest snapshot is unusable
|
|
in your environment for some reason.
|
|
|
|
If a production version of GDB has a bug and a snapshot has the fix,
|
|
and you care about stability, you should put only the fix for that
|
|
particular problem into your production version. Of course, if you
|
|
are eager to test GDB, you can use the snapshot versions in your
|
|
daily work, but users who have not been consulted about whether they
|
|
feel like testing GDB should generally have something which is at
|
|
least as bug free as the last released version.
|
|
|
|
o Providing timely response to your questions, bug reports, and
|
|
submitted patches will require the GDB development team to allocate
|
|
time from an already thin time budget. Please try to help us make
|
|
this time as productive as possible. See the section below about
|
|
how to submit changes.
|
|
|
|
|
|
HOW TO GET THE SNAPSHOTS
|
|
------------------------
|
|
|
|
The current plan is to provide a full snapshot daily, so that users getting a
|
|
snapshot for the first time, or updating after a long period of not updating,
|
|
can get the latest version in a single operation. Along with the full
|
|
snapshot, we will provide incremental diffs on a daily basis. Each daily diff
|
|
will be relative to the source tree after applying all previous daily diffs.
|
|
The daily diffs are for people who have relatively low bandwidth ftp or uucp
|
|
connections.
|
|
|
|
The files will be available via anonymous ftp from ftp.cygnus.com, in
|
|
directory pub/gdb, and should look something like:
|
|
|
|
gdb-930401.tar.z
|
|
gdb-930401-930402.diff.z
|
|
gdb-930402-930403.diff.z
|
|
gdb-930403-930404.diff.z
|
|
.
|
|
.
|
|
.
|
|
|
|
At some point, the files should automatically appear during the evening as a
|
|
result of an automatically run process each evening. For the moment however,
|
|
the process will be manually run by one of the gdb maintainers and the
|
|
appropriate files moved to the ftp area at some convenient point during the
|
|
day.
|
|
|
|
Note that the current plan is to provide GNU gzip compressed files only. You
|
|
can ftp gzip from prep.ai.mit.edu in directory pub/gnu.
|
|
|
|
Also, even though we will make the snapshots available on a publically
|
|
accessible ftp area, we ask that recipients not widely publicise their
|
|
availability. The motivation for this request is not to hoard them, but to
|
|
avoid the situation where the general GDB user base naively attempts to use
|
|
the snapshots, has trouble with them, complains publically, and the reputation
|
|
of GDB suffers because of a perception of instability or lack of quality
|
|
control.
|
|
|
|
|
|
GDB TEST SUITE
|
|
--------------
|
|
|
|
A test suite is distributed as an integral part of the snapshots. However, to
|
|
use it you will need to get a copy of the dejagnu testing framework.
|
|
Snapshots of dejagnu are available alongside the GDB snapshots, using the same
|
|
naming conventions as the GDB snapshots. Once you have installed the dejagnu
|
|
framework, a simple "make check" in the GDB directory should be sufficient to
|
|
run the tests.
|
|
|
|
Note that the test suite is still in its infancy. The test framework itself
|
|
might not install on your system if you have an environment that is not
|
|
similar to one that the GDB developers already use. The tests themselves only
|
|
cover a small portion of GDB features, and what tests do exist for a feature
|
|
are not exhaustive. New tests are welcomed.
|
|
|
|
|
|
GETTING HELP, GDB DISCUSSIONS, etc
|
|
----------------------------------
|
|
|
|
Mail sent to gdb-testers@cygnus.com goes to everyone on the list of
|
|
gdb testers, which should include everyone getting the gdb snapshots.
|
|
It is appropriate whenever you wish your mail to be seen by all the
|
|
testers. This would include announcements of any kind, notices of
|
|
intent to implement a specific enhancement (to coordinate with other
|
|
people on the list), etc. Before sending something to gdb-testers,
|
|
ask yourself if what you are about to send would be something you
|
|
would care to see show up in your mailbox if it was sent by someone
|
|
else. For administrative things ("remove me from gdb-testers", etc.),
|
|
send mail to gdb-testers-request@cygnus.com.
|
|
|
|
Mail sent to gdb-patches@cygnus.com goes to gdb support people internal to
|
|
Cygnus. Despite the name, it is appropriate for more than just patches.
|
|
Questions about the snapshots, problems accessing the snapshots, bug reports
|
|
without patches, requests for advice on how to track down a bug you have
|
|
encountered, discussion about bug fixes or enhancements in progress, etc are
|
|
all welcome in gdb-patches. Usually mail sent to gdb-patches will result in a
|
|
short private email discussion between you and one or more of the gdb
|
|
developers who can assist you with simple questions or handle your patches.
|
|
Note that gdb-patches is *not* a general gdb electronic support line. If you
|
|
are in need of such support, you probably should not be using the snapshots
|
|
and should seek out one of the commercial suppliers of support for free
|
|
software.
|
|
|
|
Do *not* send any questions about the snapshots or patches specific to the
|
|
snapshots to bug-gdb@prep.ai.mit.edu (gateway'd to the usenet group
|
|
gnu.gdb.bug). Nobody there will have any idea what you are talking about and
|
|
it will just cause confusion.
|
|
|
|
|
|
BUG REPORTS
|
|
-----------
|
|
|
|
Send bug reports to gdb-patches@cygnus.com.
|
|
|
|
Note that since no testing is done on the snapshots, and snapshots may even be
|
|
made when gdb is in an inconsistent state, it may not be unusual for an
|
|
occasional snapshot to have a very obvious bug, such as failure to compile on
|
|
*any* machine. It is likely that such bugs will be fixed by the next
|
|
snapshot, so it really isn't necessary to report them unless they persist for
|
|
a couple days.
|
|
|
|
Missing files should always be reported, since they usually mean there is a
|
|
problem with the snapshot-generating process and we won't know about them
|
|
unless someone tells us.
|
|
|
|
Bugs which are non-obvious, such as failure to compile on only a specific
|
|
machine, a new machine dependent or obscure bug (particularly one not detected
|
|
by the testsuite), etc should be reported when you discover them, or have a
|
|
suggested patch to fix them.
|
|
|
|
|
|
FORMAT FOR PATCHES
|
|
------------------
|
|
|
|
If you have a fix for a bug, or an enhancement to submit, send your patch to
|
|
gdb-patches@cygnus.com. Here are some simple guidelines for submitting
|
|
patches:
|
|
|
|
o Use "context diffs" for patches. A typical command for generating
|
|
context diffs is "diff -rc gdb-old gdb-new".
|
|
|
|
o Use the "minimalist approach" for patches. That is, each patch
|
|
should address only one particular bug, new feature, etc. Do not
|
|
save up many unrelated changes and submit them all in one big
|
|
patch, since in general, the larger the patch the more difficult
|
|
it is for us to decide if the patch is either correct or
|
|
desirable. And if we find something about the patch that needs
|
|
to be corrected before it can be installed, we would have to reject
|
|
the entire patch, which might contain changes which otherwise would
|
|
be accepted if submitted separately.
|
|
|
|
o Submit a sample ChangeLog entry with your patch. See the existing
|
|
GDB ChangeLog for examples of what a ChangeLog entry should look
|
|
like. The emacs command ^X4A will create a ChangeLog entry header
|
|
for you.
|
|
|
|
|
|
BISON and BYACC
|
|
---------------
|
|
|
|
GDB's language parsers are all portable, and can be compiled with bison,
|
|
byacc, traditional Unix yacc, or other compatible parser generators. For
|
|
various reasons, Cygnus uses byacc rather than bison by default. When a
|
|
general gdb distribution is made, this default is switched back to bison. The
|
|
snapshots follow the Cygnus default. Your options, if you do not already have
|
|
byacc installed, include:
|
|
|
|
o Hack the upper level Makefile.in lines that look like:
|
|
|
|
BISON = `if [ -f $${rootme}/byacc/byacc ] ; \
|
|
then echo $${rootme}/byacc/byacc ; \
|
|
else echo byacc ; \ <== change
|
|
fi`
|
|
|
|
to replace "byacc" with either "yacc" or "bison -y".
|
|
|
|
o Fetch the byacc snapshot from the same location as the gdb snapshots
|
|
and install byacc.
|
|
|
|
o Specify BISON=yacc on the make command line to override the default.
|
|
|
|
|
|
UNIX MAKE and GNU MAKE
|
|
----------------------
|
|
|
|
When you build gdb in the same directory as the source, you should be able to
|
|
use any available "make" that has traditional UNIX make functionality. If you
|
|
build gdb in a separate directory tree from the source, using the configure
|
|
"--srcdir" option, then only GNU make is fully supported, although other makes
|
|
with complete VPATH support should work (SunOS make for example).
|
|
|
|
|
|
|
|
Thanks for your help and support.
|
|
|
|
-Fred Fish
|
|
Cygnus Support
|