Initial GNU binutils 2.6 import

1 files changed, 295 insertions, 0 deletions

diff --git a/gnu/usr.bin/binutils/gas/README b/gnu/usr.bin/binutils/gas/README
new file mode 100644
index 00000000000..7a25d9a0844
--- /dev/null
+++ b/gnu/usr.bin/binutils/gas/README
@@ -0,0 +1,295 @@
+-*- text -*-
+
+		README for GAS
+	  [cribbed largely from GDB's README file]
+
+A number of things have changed since version 1 and the wonderful world of gas
+looks very different.  There's still a lot of irrelevant garbage lying around
+that will be cleaned up in time.  Documentation is scarce, as are logs of the
+changes made since the last gas release.  My apologies, and I'll try to get
+something useful.
+
+Unpacking and Installation - Summary
+====================================
+
+See ../binutils/README.
+
+Documentation
+=============
+
+The GAS release includes texinfo source for its manual, which can be processed
+into `info' or `dvi' forms.
+
+The DVI form is suitable for printing or displaying; the commands for doing
+this vary from system to system.  On many systems, `lpr -d' will print a DVI
+file.  On others, you may need to run a program such as `dvips' to convert the
+DVI file into a form your system can print.
+
+If you wish to build the DVI file, you will need to have TeX installed on your
+system.  You can rebuild it by typing:
+
+	cd gas-2.5/gas/doc
+	make as.dvi
+
+The Info form is viewable with the GNU Emacs `info' subsystem, or the
+standalone `info' program, available as part of the GNU Texinfo distribution.
+To build the info files, you will need the `makeinfo' program.  Type:
+
+	cd gas-2.5/gas/doc
+	make info
+
+Specifying names for hosts and targets
+======================================
+
+   The specifications used for hosts and targets in the `configure'
+script are based on a three-part naming scheme, but some short
+predefined aliases are also supported.  The full naming scheme encodes
+three pieces of information in the following pattern:
+
+     ARCHITECTURE-VENDOR-OS
+
+   For example, you can use the alias `sun4' as a HOST argument or in a
+`--target=TARGET' option.  The equivalent full name is
+`sparc-sun-sunos4'.
+
+   The `configure' script accompanying GAS does not provide any query
+facility to list all supported host and target names or aliases. 
+`configure' calls the Bourne shell script `config.sub' to map
+abbreviations to full names; you can read the script, if you wish, or
+you can use it to test your guesses on abbreviations--for example:
+
+     % sh config.sub sun4
+     sparc-sun-sunos411
+     % sh config.sub sun3
+     m68k-sun-sunos411
+     % sh config.sub decstation
+     mips-dec-ultrix42
+     % sh config.sub hp300bsd
+     m68k-hp-bsd
+     % sh config.sub i386v
+     i386-unknown-sysv
+     % sh config.sub i786v
+     Invalid configuration `i786v': machine `i786v' not recognized
+
+`config.sub' is also distributed in the GAS source directory
+(`gas-2.5', for version 2.5).
+
+
+`configure' options
+===================
+
+   Here is a summary of the `configure' options and arguments that are
+most often useful for building GAS.  `configure' also has several other
+options not listed here.
+
+     configure [--help]
+               [--prefix=DIR]
+               [--srcdir=PATH]
+               [--norecursion] [--rm]
+               [--target=TARGET] HOST
+               [--with-OPTION]
+               [--enable-OPTION]
+
+You may introduce options with a single `-' rather than `--' if you
+prefer; but you may abbreviate option names if you use `--'.
+
+`--help'
+     Display a quick summary of how to invoke `configure'.
+
+`-prefix=DIR'
+     Configure the source to install programs and files under directory
+     `DIR'.
+
+`--srcdir=PATH'
+     *Warning: using this option requires GNU `make', or another `make'
+     that implements the `VPATH' feature.*
+     Use this option to make configurations in directories separate
+     from the GAS source directories.  Among other things, you can use
+     this to build (or maintain) several configurations simultaneously,
+     in separate directories.  `configure' writes configuration
+     specific files in the current directory, but arranges for them to
+     use the source in the directory PATH.  `configure' will create
+     directories under the working directory in parallel to the source
+     directories below PATH.
+
+`--norecursion'
+     Configure only the directory level where `configure' is executed;
+     do not propagate configuration to subdirectories.
+
+`--rm'
+     Remove the configuration that the other arguments specify.
+
+`--target=TARGET'
+     Configure GAS for cross-assembling programs for the specified
+     TARGET.  Without this option, GAS is configured to assemble .o files
+     that run on the same machine (HOST) as GAS itself.
+
+     There is no convenient way to generate a list of all available
+     targets.
+
+`--enable-OPTION'
+     These flags tell the program or library being configured to 
+     configure itself differently from the default for the specified
+     host/target combination.  See below for a list of `--enable'
+     options recognized in the gas-2.5 distribution.
+
+`HOST ...'
+     Configure GAS to run on the specified HOST.
+
+     There is no convenient way to generate a list of all available
+     hosts.
+
+`configure' accepts other options, for compatibility with configuring
+other GNU tools recursively; but these are the only options that affect
+GAS or its supporting libraries.
+
+The `--enable' options recognized by software in the gas-2.5 distribution are:
+
+`--enable-targets=...'
+     This causes one or more specified configurations to be added to those for
+     which BFD support is compiled.  Currently gas cannot use any format other
+     than its compiled-in default, so this option is not very useful.
+
+`--enable-bfd-assembler'
+     This causes the assembler to use the new code being merged into it to use
+     BFD data structures internally, and use BFD for writing object files.
+     For most targets, this isn't supported yet.  For most targets where it has
+     been done, it's already the default.  So generally you won't need to use
+     this option.  See `BFD CONVERSION' in the file `gas/NOTES'.
+
+Supported platforms
+===================
+
+At this point I believe gas to be ansi only code for most target cpu's.  That
+is, there should be relatively few, if any host system dependencies.  So
+porting (as a cross-assembler) to hosts not yet supported should be fairly
+easy.  Porting to a new target shouldn't be too tough if it's a variant of one
+already supported.
+
+Native assembling should work on:
+
+	sun3
+	sun4
+	386bsd
+	bsd/386
+	delta (m68k-sysv from Motorola)
+	delta88 (m88k-sysv from Motorola)
+	linux
+	m68k hpux 8.0 (hpux 7.0 may be a problem)
+	vax bsd, ultrix, vms
+	hp9000s300
+	decstation
+	iris
+	miniframe (m68k-sysv from Convergent Technologies)
+	i386-aix (ps/2)
+	hppa (hpux 4.3bsd, osf1)
+	rs6000
+	unixware
+	sco 3.2v4.2
+	sparc solaris 2.3
+
+For cross-assemblers, I believe hosting to work on any of the machines listed
+above, plus:
+
+	sun386i
+	at least some flavors of hpux (hpux 7.0 may be a problem)
+	most flavors of sysV
+
+I believe that gas as a cross-assembler can currently be targetted for:
+
+	386bsd
+	bsd/386
+	decstation-bsd (a.out format, to be used in BSD 4.4)
+	ebmon29k
+	go32 (DOS on i386, with DJGPP -- old a.out version)
+	h8/300, h8/500 (Hitachi)
+	hp9000/300
+	i386-aix (ps/2)
+	i960-coff
+	linux
+	mips ecoff (decstation-ultrix, iris, mips magnum, mips-idt-ecoff)
+	nindy960
+	powerpc
+	sco386
+	sun3
+	sun4
+	vax bsd or ultrix?
+	vms
+	vxworks68k
+	vxworks960
+	z8000 (Zilog)
+
+MIPS ECOFF support has been added, but GAS will not run a C-style
+preprocessor.  If you want that, rename your file to have a ".S" suffix, and
+run gcc on it.  Or run "gcc -xassembler-with-cpp foo.s".
+
+Support for ELF should work now for sparc, hppa, i386.
+
+Support for ns32k, tahoe, i860, m88k may be suffering from bitrot.
+
+If you try out gas on some host or target not listed above, please let me know
+the results, so I can update the list.
+
+Compiler Support Hacks
+======================
+
+The assembler has been modified to support a feature that is potentially
+useful when assembling compiler output, but which may confuse assembly
+language programmers.  If assembler encounters a .word pseudo-op of the form
+symbol1-symbol2 (the difference of two symbols), and the difference of those
+two symbols will not fit in 16 bits, the assembler will create a branch around
+a long jump to symbol1, and insert this into the output directly before the
+next label: The .word will (instead of containing garbage, or giving an error
+message) contain (the address of the long jump)-symbol2.  This allows the
+assembler to assemble jump tables that jump to locations very far away into
+code that works properly.  If the next label is more than 32K away from the
+.word, you lose (silently); RMS claims this will never happen.  If the -K
+option is given, you will get a warning message when this happens.
+
+
+REPORTING BUGS IN GAS
+=====================
+
+Bugs in gas should be reported to bug-gnu-utils@prep.ai.mit.edu.  They may be
+cross-posted to bug-gcc if they affect the use of gas with gcc.  They should
+not be reported just to bug-gcc, since I don't read that list, and therefore
+wouldn't see them.
+
+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 avaliable 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.