-This is the beta-test version of the GNU assembler. (Probably
-around Version 1.38, but check version.c which gets updated more
-often than this readme.)
-
-These files are currently set up to allow you to compile all of the
-versions of the assembler on the same machine. 'make all' compiles
-all of them. The resulting executable names are:
-
- 68020 a68
- Vax avax
- NS 32xxx a32k
- Intel 80386 a386
- SPARC asparc
- AMD 29000 asm29k
-
-The Makefile contains instructions on how to make one of the
-assemblers compile as the default.
-
-Before you can compile the 68020 version of the assembler, you must
-make m68k.h be a link to m-sun3.h , m-hpux.h or m-generic.h . If
-you are on a SUN-3 (or other machine that uses a magic number of
-(2 << 16) | OMAGIC type 'ln -s m-sun3.h m68k.h' else if you are on a
-machine running HP-UX, type 'ln m-hpux.h m689k.h' else type
-'ln -s m-generic.h m68k.h' If your machine does not support symbolic
-links, omit the '-s'.
-
-See the instructions in the Makefile for compiling gas for the Sequent
-Symmetry (dynix 3.0.12 + others?) or for the HP 9000/300
-
-If your machine does not have both varargs.h and vfprintf(), but does have
-_doprnt() add -DNO_VARARGS to the CFLAGS line in the makefile. If your
-machine has neither vfprintf() or _doprnt(), you will have to change
-messages.c in order to get readable error messages from the assembler.
-
-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.
-
+ README for GAS
- REPORTING BUGS IN GAS
+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.
-Bugs in gas should be reported to bug-gnu-utils@prep.ai.mit.edu If you can't
-get through to prep, try hack@gnu.ai.mit.edu or hack@media-lab.media.mit.edu
+Unpacking and Installation - Summary
+====================================
-If you report a bug in GAS, please remember to include:
+See ../binutils/README.
-A description of exactly what went wrong.
+To build just the assembler, make the target all-gas.
-The type of machine GAS was running on (VAX, 68020, etc),
+Documentation
+=============
-The Operating System GAS was running under.
+The GAS release includes texinfo source for its manual, which can be processed
+into `info' or `dvi' forms.
-The options given to GAS.
+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.
-The actual input file that caused the problem.
+If you wish to build the DVI file, you will need to have TeX installed on your
+system. You can rebuild it by typing:
-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.
+ cd gas/doc
+ make as.dvi
-To save us these delays and uncertainties, always send the input file
-for the program that failed.
+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:
-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.
+ cd gas/doc
+ make info
------------------------------- README.APOLLO ---------------------------------
+Specifying names for hosts and targets
+======================================
-The changes required to get the GNU C compiler running on
-Apollo 68K platforms are available via anonymous ftp from
-labrea.stanford.edu (36.8.0.47) in the form of a compressed
-tar file named "/pub/gnu/apollo-gcc-1.37.tar.Z".
-The size of the file is 84145 bytes.
+ 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:
-To build GCC for the Apollo you'll need the virgin FSF
-distributions of bison-1.03, gas-1.34, and gcc-1.37. They
-are also on labrea.stanford.edu as well as prep.ai.mit.edu.
-My changes are to enable gas to produce Apollo COFF object
-files and allow gcc to parse some of the syntax extensions
-which appear in Apollo C header files. Note that the
-COFF encapsulation technique cannot be used on the Apollo.
-
-The tar file should be unpacked in the directory containing
-the gas-1.34 and gcc-1.37 directories; a few files will be overlaid,
-and an APOLLO-GCC-README file will appear in the top directory.
-This file contains detailed instructions on how to proceed.
+ 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'.
-These changes will only work for SR10.1 or later systems, using
-the 6.6 or later version of the Apollo C compiler.
+ 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
+
+
+`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]
+ [--host=HOST]
+ [--target=TARGET]
+ [--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'
+ Print a summary of the options to `configure', and exit.
+
+`-prefix=DIR'
+ Configure the source to install programs and files under directory
+ `DIR'.
+
+`--srcdir=PATH'
+ Look for the package's source code in directory DIR. Usually
+ `configure' can determine that directory automatically.
+
+`--host=HOST'
+ Configure GAS to run on the specified HOST. Normally the
+ configure script can figure this out automatically.
+
+ There is no convenient way to generate a list of all available
+ hosts.
+
+`--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 distribution.
+
+`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 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.
+
+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)
+ GNU/linux
+ m68k hpux 8.0 (hpux 7.0 may be a problem)
+ vax bsd, ultrix, vms
+ hp9000s300
+ decstation
+ irix 4
+ irix 5
+ miniframe (m68k-sysv from Convergent Technologies)
+ i386-aix (ps/2)
+ hppa (hpux 4.3bsd, osf1)
+ AIX
+ unixware
+ sco 3.2v4.2
+ sco openserver 5.0 (a.k.a. 3.2v5.0 )
+ sparc solaris
+ ns32k (netbsd, lites)
+
+I believe that gas as a cross-assembler can currently be targetted for
+most of the above hosts, plus
+
+ 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)
+ i386-aix (ps/2)
+ i960-coff
+ mips ecoff (decstation-ultrix, iris, mips magnum, mips-idt-ecoff)
+ Mitsubishi d10v and d30v
+ nindy960
+ powerpc EABI
+ SH (Hitachi)
+ sco386
+ TI tic30 and tic80
+ 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, alpha, m68k,
+MIPS, powerpc.
+
+Support for sequent (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
+======================
+
+On a few targets, 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.
-If you do not have ftp access, I can mail you the changes in the
-form of diffs; they are approximately 40K in length. If you request
-them, be sure to give me a voice phone number so I can contact you
-in case I can't send you mail; I've had several requests in the
-past from people I can't contact.
-By the way, I'm working on getting the GNU C++ compiler running;
-there are a couple problems to solve. I hope to be able to announce
-the Apollo version shortly after the 1.37 version is released.
+REPORTING BUGS IN GAS
+=====================
-John Vasta Hewlett-Packard Apollo Systems Division
-vasta@apollo.hp.com M.S. CHA-01-LT
-(508) 256-6600 x6362 300 Apollo Drive, Chelmsford, MA 01824
-UUCP: {decwrl!decvax, mit-eddie, attunix}!apollo!vasta
+Bugs in gas should be reported to bug-gnu-utils@gnu.org. 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:
-You might refer others who are interested in a similar thing.
+A description of exactly what went wrong, and exactly what should have
+happened instead.
-Kevin Buchs buchs@mayo.edu
+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.
------------------------------- README.COFF -----------------------------------
+The options given to GAS at run time.
-If you have a COFF system, you may wish to aquire
+The actual input file that caused the problem.
- UUCP: osu-cis!~/gnu/coff/gnu-coff.tar.Z
- or
- FTP: tut.cis.ohio-state.edu:/pub/gnu/coff/gnu-coff.tar.Z
+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.
-These contain patches for gas that will make it produce COFF output.
-I have never seen these patches, so I don't know how well they work.
+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.
projects / deliverable / binutils-gdb.git / blobdiff