Expand and consolidate bug reporting details.
This commit is contained in:
Alan Modra
parent
7de2341de5
commit
36fd3cc348
4 changed files with 69 additions and 40 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
===
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
41
gas/README
41
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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue