`sparc-sun-sunos4'.
The `configure' script accompanying GAS does not provide any query
-facility to list all supported host and target names or aliases.
+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
targets.
`--enable-OPTION'
- These flags tell the program or library being configured to
+ 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.
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 targeted for
-most of the above hosts, plus
-
- arm
- 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 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
======================
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.
+See ../binutils/README for what we need in a bug report.
+\f
+Copyright (C) 2012-2020 Free Software Foundation, Inc.
-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.
+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.
projects / deliverable / binutils-gdb.git / blobdiff