|
|
|
@ -1,19 +1,19 @@ |
|
|
|
GDB SNAPSHOT SYSTEM |
|
|
|
(general info) |
|
|
|
Updated 5/24/93 |
|
|
|
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. |
|
|
|
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. |
|
|
|
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: |
|
|
|
|
|
|
|
@ -68,9 +68,13 @@ This has several advantages, and several disadvantages. |
|
|
|
HOW TO GET THE SNAPSHOTS |
|
|
|
------------------------ |
|
|
|
|
|
|
|
The current plan is to provide a full snapshot once weekly, and incremental |
|
|
|
diffs on a daily basis. Each daily diff will be relative to the source |
|
|
|
tree for the previous day after applying all incremental diffs to date. |
|
|
|
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: |
|
|
|
@ -83,39 +87,39 @@ directory pub/gdb, and should look something like: |
|
|
|
. |
|
|
|
. |
|
|
|
|
|
|
|
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. |
|
|
|
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. |
|
|
|
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, as the gcc developers did with their gcc snapshot system, 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 declines because |
|
|
|
of a perception of instability or lack of quality control. |
|
|
|
Also, as the gcc developers did with their gcc snapshot system, 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 declines 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. |
|
|
|
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. |
|
|
|
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 |
|
|
|
@ -123,30 +127,30 @@ 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. |
|
|
|
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. |
|
|
|
|
|
|
|
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 |
|
|
|
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. |
|
|
|
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. |
|
|
|
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 |
|
|
|
@ -154,29 +158,29 @@ 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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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: |
|
|
|
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". |
|
|
|
@ -201,11 +205,11 @@ 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: |
|
|
|
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: |
|
|
|
|
|
|
|
@ -225,11 +229,11 @@ have byacc installed, include: |
|
|
|
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). |
|
|
|
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). |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@ -237,4 +241,3 @@ Thanks for your help and support. |
|
|
|
|
|
|
|
-Fred Fish |
|
|
|
Cygnus Support |
|
|
|
|
|
|
|
|
Fred Fish
33 years ago