1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
|
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
|
