README for 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.
+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
====================================
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.
+stand-alone `info' program, available as part of the GNU Texinfo distribution.
To build the info files, you will need the `makeinfo' program. Type:
cd gas/doc
Supported platforms
===================
-At this point I believe gas to be ansi only code for most target cpu's. That
+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
sparc solaris
ns32k (netbsd, lites)
-I believe that gas as a cross-assembler can currently be targetted for
+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)
+ H8/300, H8/500 (Hitachi)
i386-aix (ps/2)
i960-coff
mips ecoff (decstation-ultrix, iris, mips magnum, mips-idt-ecoff)
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.
+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.
REPORTING BUGS IN GAS
=====================
-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.
+Bugs in gas should be reported to:
-If you report a bug in GAS, please remember to include:
+ bug-binutils@gnu.org.
-A description of exactly what went wrong, and exactly what should have
-happened instead.
+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.
-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.
+See ../binutils/README for what we need in a bug report.
projects / deliverable / binutils-gdb.git / blobdiff