This is a pre-alpha version of the GNU assembler, version 1.92.3.
(this is a copy of the mail announcement. Real README follows below.)
This session I merged the m88k support. It configures, builds, and
assembles things, including some gcc2 output. I have no way of
knowing if the output is right.
I've merged the tahoe support. It configures and builds. I couldn't
build the cygnus version of gcc2 for this machine, so I have no idea
whether gas is assembling anything at all for it.
I've walked through my bug and patch archives. Gas now makes a
tolerable guess at a.out headers for hpux and sequent, although I have
no way to know if these are right yet.
Ming tran-le's changes for 386aix will probably drop out soon. He
needs multiple segments and I don't plan to get that in before the
real release.
Eric youngdale's help with vms has been invaluable. According to him,
this gas is doing vms. I didn't quite get a cross to vms working and
don't plan to spend any more time on it.
The gas manual is included in the distribution, configuration, and
Makefiles. It should build, be printable, and readable through info.
I have not yet verified that this gas has all of the unreleased
changes that hack made after the last gas release. At this point I
plan to ignore these until those bugs are re-reported in an alpha or
full release I don't think it's worth my time.
I have not yet verified any hosts other than sun4, although I have
three-staged sun3 native.
I have not updated the configuration doc.
I do not plan to bring in any new backends for the upcoming release
unless someone hands them to me on a platter as eric did for vms. I
merged the m88k and tahoe ports because they were simple for me at
this point, but would have been difficult for someone else. I may yet
do this for the ncube support as well.
I've looked at the osf stuff and discarded it for this release. I'm
not sure I like what they've done for macho object format and without
macho headers, I can't even build their version.
I've looked at the utah stuff and discarded it for this release.
They, too, have made some sweeping changes to support their object
format that I'm not sure were necessary. In any case, merging this
would be too much work for me right now.
I've looked at the tron port. It's remarkably clean and it's a.out
format. I don't plan to merge this for the full release for two
reasons. First, it's so clean, they will be able to add their stuff
on top and build a seperate distribution without much trouble.
Second, I'm get responses from them, and hope that they will be able
to do the merge.
To do before alpha:
* merge patches and address bugs as they arrive.
* kill a remaining bug. The following input:
.text
a .word 3
b .word 4
c .half b-a
kills most risc ports. I believe that this represents a failing of
the internal representation of relocs (aka fixS's). The fix is
relatively straightforward and I intend to make it.
* add autoconf style configuration for hosts (not targets).
* test via three-staging (preferably with gcc2) on all a.out based
machines to which I have access.
* update/clean out README's and build a brief porting guide.
There is still a copyright issue on the coff back end, so it may need
to be pulled for the full release. If this gets resolved, I hope to
see coff run personally on at least one native machine before full
release.
Real README:
This is a pre-alpha version of the GNU assembler, version 1.92.3.
A number of things have changed and the wonderful world of gas looks
very different. There's still a lot of irrelevant garbage lying
around that will be cleaned up soon. The gas manual now builds and
installs, but internal documentation is still scarce, as are logs of
the changes made since the last gas release. My apologies, and I'll
try to get something useful
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. Most of my recent effort has been spent testing and
dusting off ports for which Cygnus hasn't had recent need.
Hosting has recently been tested on only:
sun4
sun3
I believe that gas can currently be targetted for:
sun4
sun3
and "ports" for other cpu's and object file formats from the following
set are probably trivial at this point:
a.out
a29k
i386
i860
i960
m68k
m88k
ns32k
tahoe
sparc
vax
I have tested most of these in "generic" a.out configurations so I
feel pretty confident in them. If anything else works, it's an
accident.
Some ports now generate object files that are somewhat differently
shaped, but should be more correct. Specifically:
* Most a.out ports now sort the relocation table in numerically
ascending order. In previous versions of gas, the relocation table
was sorted in descending order. To get the previous functionality,
compile with -DREVERSE_SORT_RELOCS.
* ns32k: The last gas I have from hack simply looks broken for ns32k.
I think this one works, but don't have an assembler that I trust
against which to compare.
* i386: now uses ".align x" to mean x bytes rather than 2^x bytes. It
also pads with the noop instruction rather than zeroes.
In all cases, compiling with -DOLD_GAS will produce an assembler that
should produce object files that are bitwise identical to the previous
version of gas.
NEW FEATURES!
This isn't a complete catalog. I've forgotten what all has been done.
* support for i960, a29k, m88k, and tahoe.
* support for 68030 and 68040, including the ability to limit the
instructions that gas will accept. ie, you can assemble for EXACTLY
68000 and no more.
* object file formats have been broken out into separate backends.
* a new "backend" has been created to represent the target
environment. That is, gas now mimics various other assemblers
rather than creating it's own requirements. A side effect of this
is that this version of gas may not behave the same way as previous
versions.
* ansi. gas is now strictly ansi code so host ports should be
trivial.
REPORTING BUGS IN GAS
Bugs in THIS RELEASE of gas should be reported directly to
rich@cygnus.com. NOT to bug-gnu-utils@prep.ai.mit.edu.
If you report a bug in GAS, please remember to include:
A description of exactly what went wrong.
How GAS was configured,
The Operating System GAS was running under.
The options given to GAS.
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.
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.
5baccad631