diff options
Diffstat (limited to 'gnu/usr.bin/binutils/gas/README')
| -rw-r--r-- | gnu/usr.bin/binutils/gas/README | 295 |
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. |