diff options
| -rw-r--r-- | binutils/ChangeLog | 4 | ||||
| -rw-r--r-- | binutils/README | 59 | ||||
| -rw-r--r-- | gas/ChangeLog | 5 | ||||
| -rw-r--r-- | gas/README | 41 |
4 files changed, 69 insertions, 40 deletions
diff --git a/binutils/ChangeLog b/binutils/ChangeLog index 315a4d4..722c4d4 100644 --- a/binutils/ChangeLog +++ b/binutils/ChangeLog @@ -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 diff --git a/binutils/README b/binutils/README index 936f25f..5bc2508 100644 --- a/binutils/README +++ b/binutils/README @@ -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 === 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 @@ -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. |