+
+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, particularly so
+when the bug report is against an old version. If you are able, please
+consider building the latest tools from git 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
+===
+
+This section was written by Klaus K"ampf <kkaempf@rmi.de>. It
+describes how to build and install the binutils on openVMS (Alpha and
+Vax). (The BFD library only supports reading Vax object files.)
+
+Compiling the release:
+
+To compile the gnu binary utilities and the gnu assembler, you'll
+need DEC C or GNU C for openVMS/Alpha. You'll need *both* compilers
+on openVMS/Vax.
+
+Compiling with either DEC C or GNU C works on openVMS/Alpha only. Some
+of the opcodes and binutils files trap a bug in the DEC C optimizer,
+so these files must be compiled with /noopt.
+
+Compiling on openVMS/Vax is a bit complicated, as the bfd library traps
+a bug in GNU C and the gnu assembler a bug in (my version of) DEC C.
+
+I never tried compiling with VAX C.
+
+
+You further need GNU Make Version 3.76 or later. This is available
+at ftp.progis.de or any GNU archive site. The makefiles assume that
+gmake starts gnu make as a foreign command.
+
+If you're compiling with DEC C or VAX C, you must run
+
+ $ @setup
+
+before starting gnu-make. This isn't needed with GNU C.
+
+On the Alpha you can choose the compiler by editing the toplevel
+makefile.vms. Either select CC=cc (for DEC C) or CC=gcc (for GNU C)
+
+
+Installing the release
+
+Provided that your directory setup conforms to the GNU on openVMS
+standard, you already have a concealed device named 'GNU_ROOT'.
+In this case, a simple
+
+ $ gmake install
+
+suffices to copy all programs and libraries to the proper directories.
+
+Define the programs as foreign commands by adding these lines to your
+login.com:
+
+ $ gas :== $GNU_ROOT:[bin]as.exe
+ $ size :== $GNU_ROOT:[bin]size.exe
+ $ nm :== $GNU_ROOT:[bin]nm.exe
+ $ objdump :== $GNU_ROOT:[bin]objdump.exe
+ $ strings :== $GNU_ROOT:[bin]strings.exe
+
+If you have a different directory setup, copy the binary utilities
+([.binutils]size.exe, [.binutils]nm.exe, [.binutils]objdump.exe,
+and [.binutils]strings.exe) and the gnu assembler and preprocessor
+([.gas]as.exe and [.gas]gasp.exe]) to a directory of your choice
+and define all programs as foreign commands.
+
+
+If you're satisfied with the compilation, you may want to remove
+unneeded objects and libraries:
+
+ $ gmake clean
+
+
+If you have any problems or questions about the binutils on VMS, feel
+free to mail me at kkaempf@rmi.de.
+\f
+Copyright (C) 2012-2019 Free Software Foundation, Inc.
+
+Copying and distribution of this file, with or without modification,
+are permitted in any medium without royalty provided the copyright
+notice and this notice are preserved.