Expand and consolidate bug reporting details.

This commit is contained in:
Alan Modra 2003-11-10 03:06:05 +00:00
parent 7de2341de5
commit 36fd3cc348
4 changed files with 69 additions and 40 deletions

View File

@ -1,3 +1,7 @@
2003-11-10 Alan Modra <amodra@bigpond.net.au>
* README: Expand bug reporting information.
2003-11-07 Jonathan R. Grant <jg-binutils@jguk.org>
* bucomm,c (get_file_size): New function. Returns the size of a

View File

@ -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
===

View File

@ -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

View File

@ -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.