aboutsummaryrefslogtreecommitdiff
path: root/gas
diff options
context:
space:
mode:
authorAlan Modra <amodra@gmail.com>2003-11-10 03:06:05 +0000
committerAlan Modra <amodra@gmail.com>2003-11-10 03:06:05 +0000
commit36fd3cc3487d6e2858581d4d752cc387929f322d (patch)
tree9ed17be474cb97a7b2e1c7fe31d80b7440784682 /gas
parent7de2341de55ac437100dd6d0ad1fcab41fcae8c4 (diff)
downloadgdb-36fd3cc3487d6e2858581d4d752cc387929f322d.zip
gdb-36fd3cc3487d6e2858581d4d752cc387929f322d.tar.gz
gdb-36fd3cc3487d6e2858581d4d752cc387929f322d.tar.bz2
Expand and consolidate bug reporting details.
Diffstat (limited to 'gas')
-rw-r--r--gas/ChangeLog5
-rw-r--r--gas/README41
2 files changed, 7 insertions, 39 deletions
diff --git a/gas/ChangeLog b/gas/ChangeLog
index 239c95d..29bb02f 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,8 @@
+2003-11-10 Alan Modra <amodra@bigpond.net.au>
+
+ * README: Update bug report address. Move bug reporting info to
+ binutils/README.
+
2003-11-07 Christian Groessler <chris@groessler.org>
* doc/c-z8k.texi: Document command-line options. Fix byte
diff --git a/gas/README b/gas/README
index 319fda9..7905395 100644
--- a/gas/README
+++ b/gas/README
@@ -232,47 +232,10 @@ REPORTING BUGS IN GAS
Bugs in gas should be reported to:
- bug-gnu-utils@gnu.org.
+ bug-binutils@gnu.org.
They may be cross-posted to gcc-bugs@gnu.org if they affect the use of
gas with gcc. They should not be reported just to gcc-bugs, since not
all of the maintainers read that list.
-If you report a bug in GAS, please remember to include:
-
-A description of exactly what went wrong, and exactly what should have
-happened instead.
-
-The type of machine (VAX, 68020, etc) and operating system (BSD, SunOS, DYNIX,
-VMS, etc) GAS was running on.
-
-The configuration name(s) given to the "configure" script. The
-"config.status" file should have this information.
-
-The options given to GAS at run time.
-
-The actual input file that caused the problem.
-
-It is silly to report a bug in GAS without including an input file for GAS.
-Don't ask us to generate the file just because you made it from files you
-think we have access to.
-
-1. You might be mistaken.
-2. It might take us a lot of time to install things to regenerate that file.
-3. We might get a different file from the one you got, and might not see any
- bug.
-
-To save us these delays and uncertainties, always send the input file for the
-program that failed. A smaller test case that demonstrates the problem is of
-course preferable, but be sure it is a complete input file, and that it really
-does demonstrate the problem; but if paring it down would cause large delays
-in filing the bug report, don't bother.
-
-If the input file is very large, and you are on the internet, you may want to
-make it available for anonymous FTP instead of mailing it. If you do, include
-instructions for FTP'ing it in your bug report.
-
-If you expect to be contributing a large number of test cases, it would be
-helpful if you would look at the test suite included in the release (based on
-the Deja Gnu testing framework, available from the usual ftp sites) and write
-test cases to fit into that framework. This is certainly not required.
+See ../binutils/README for what we need in a bug report.