Updated bug reporting instrutions

[Alan Modra <amodra at bigpond dot net dot au>]

On Sun, Nov 09, 2003 at 07:36:53PM -0500, Ian Lance Taylor wrote:
[ subject was Re: Some ppc fixes breaks on sparc]
> I like this.  See also the text in gas/README.  (Also the bug
> reporting address there should be updated to bug-binutils).

I forgot about the text already in gas/README.  This merges the text
there with what I wrote, to binutils/README.

gas/ChangeLog
	* README: Update bug report address.  Move bug reporting info
	to binutils/README.

binutils/ChangeLog
	* README: Expand bug reporting information.

Committing this as is.  It's probably easier for people to edit this in
place than discuss wording and so forth on the mailing list.

Index: binutils/README
===================================================================
RCS file: /cvs/src/src/binutils/README,v
retrieving revision 1.7
diff -u -p -r1.7 README
--- binutils/README	24 Feb 2003 16:37:13 -0000	1.7
+++ binutils/README	10 Nov 2003 02:45:10 -0000
@@ -139,9 +139,66 @@ Send bug reports and patches to:
 
    bug-binutils@gnu.org.
 
+Please include the following in bug reports:
+
+- A description of exactly what went wrong, and exactly what should have
+  happened instead.
+
+- The configuration name(s) given to the "configure" script.  The
+  "config.status" file should have this information.  This is assuming
+  you built binutils yourself.  If you didn't build binutils youself,
+  then we need information regarding your machine and operating system,
+  and it may be more appropriate to report bugs to wherever you obtained
+  binutils.
+
+- The options given to the tool (gas, objcopy, ld etc.) at run time.
+
+- The actual input file that caused the problem.
+
 Always mention the version number you are running; this is printed by
 running any of the binutils with the --version option.  We appreciate
-reports about bugs, but we do not promise to fix them.
+reports about bugs, but we do not promise to fix them, particularly so
+when the bug report is against an old version.  If you are able, please
+consider building the latest tools from CVS to check that your bug has
+not already been fixed.
+
+When reporting problems about gas and ld, it's useful to provide a
+testcase that triggers the problem.  In the case of a gas problem, we
+want input files to gas and command line switches used.  The inputs to
+gas are _NOT_ .c or .i files, but rather .s files.  If your original
+source was a C program, you can generate the .s file and see the command
+line options by passing -v -save-temps to gcc in addition to all the
+usual options you use.  The reason we don't want C files is that we
+might not have a C compiler around for the target you use.  While it
+might be possible to build a compiler, that takes considerable time and
+disk space, and we might not end up with exactly the same compiler you
+use.
+
+In the case of a ld problem, the input files are .o, .a and .so files,
+and possibly a linker script specified with -T.  Again, when using gcc
+to link, you can see these files by adding options to the gcc command
+line.  Use -v -save-temps -Wl,-t, except that on targets that use gcc's
+collect2, you would add -v -save-temps -Wl,-t,-debug.  The -t option
+tells ld to print all files and libraries used, so that, for example,
+you can associate -lc on the ld command line with the actual libc used.
+Note that your simple two line C program to trigger a problem typically
+expands into several megabytes of objects by the time you include
+libraries.
+
+It is antisocial to post megabyte sized attachments to mailing lists, so
+please put large testcases somewhere on an ftp or web site so that only
+interested developers need to download them, or offer to email them on
+request.  Better still, try to reduce the testcase, for example, try to
+develop a ld testcase that doesn't use system libraries.  However,
+please be sure it is a complete testcase and that it really does
+demonstrate the problem.  Also, don't bother paring it down if that will
+cause large delays in filing the 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.
 
 VMS
 ===
Index: gas/README
===================================================================
RCS file: /cvs/src/src/gas/README,v
retrieving revision 1.5
diff -u -p -r1.5 README
--- gas/README	17 Dec 2002 01:13:54 -0000	1.5
+++ gas/README	10 Nov 2003 02:45:10 -0000
@@ -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.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre