1 This is a pre-alpha version of the GNU assembler, version 1.92.3.
3 (this is a copy of the mail announcement. Real README follows below.)
5 This session I merged the m88k support. It configures, builds, and
6 assembles things, including some gcc2 output. I have no way of
7 knowing if the output is right.
9 I've merged the tahoe support. It configures and builds. I couldn't
10 build the cygnus version of gcc2 for this machine, so I have no idea
11 whether gas is assembling anything at all for it.
13 I've walked through my bug and patch archives. Gas now makes a
14 tolerable guess at a.out headers for hpux and sequent, although I have
15 no way to know if these are right yet.
17 Ming tran-le's changes for 386aix will probably drop out soon. He
18 needs multiple segments and I don't plan to get that in before the
21 Eric youngdale's help with vms has been invaluable. According to him,
22 this gas is doing vms. I didn't quite get a cross to vms working and
23 don't plan to spend any more time on it.
25 The gas manual is included in the distribution, configuration, and
26 Makefiles. It should build, be printable, and readable through info.
28 I have not yet verified that this gas has all of the unreleased
29 changes that hack made after the last gas release. At this point I
30 plan to ignore these until those bugs are re-reported in an alpha or
31 full release I don't think it's worth my time.
33 I have not yet verified any hosts other than sun4, although I have
34 three-staged sun3 native.
36 I have not updated the configuration doc.
38 I do not plan to bring in any new backends for the upcoming release
39 unless someone hands them to me on a platter as eric did for vms. I
40 merged the m88k and tahoe ports because they were simple for me at
41 this point, but would have been difficult for someone else. I may yet
42 do this for the ncube support as well.
44 I've looked at the osf stuff and discarded it for this release. I'm
45 not sure I like what they've done for macho object format and without
46 macho headers, I can't even build their version.
48 I've looked at the utah stuff and discarded it for this release.
49 They, too, have made some sweeping changes to support their object
50 format that I'm not sure were necessary. In any case, merging this
51 would be too much work for me right now.
53 I've looked at the tron port. It's remarkably clean and it's a.out
54 format. I don't plan to merge this for the full release for two
55 reasons. First, it's so clean, they will be able to add their stuff
56 on top and build a seperate distribution without much trouble.
57 Second, I'm get responses from them, and hope that they will be able
63 * merge patches and address bugs as they arrive.
65 * kill a remaining bug. The following input:
72 kills most risc ports. I believe that this represents a failing of
73 the internal representation of relocs (aka fixS's). The fix is
74 relatively straightforward and I intend to make it.
76 * add autoconf style configuration for hosts (not targets).
78 * test via three-staging (preferably with gcc2) on all a.out based
79 machines to which I have access.
81 * update/clean out README's and build a brief porting guide.
83 There is still a copyright issue on the coff back end, so it may need
84 to be pulled for the full release. If this gets resolved, I hope to
85 see coff run personally on at least one native machine before full
91 This is a pre-alpha version of the GNU assembler, version 1.92.3.
93 A number of things have changed and the wonderful world of gas looks
94 very different. There's still a lot of irrelevant garbage lying
95 around that will be cleaned up soon. The gas manual now builds and
96 installs, but internal documentation is still scarce, as are logs of
97 the changes made since the last gas release. My apologies, and I'll
98 try to get something useful
100 At this point I believe gas to be ansi only code for most target
101 cpu's. That is, there should be relatively few, if any host system
102 dependencies. Most of my recent effort has been spent testing and
103 dusting off ports for which Cygnus hasn't had recent need.
105 Hosting has recently been tested on only:
110 I believe that gas can currently be targetted for:
115 and "ports" for other cpu's and object file formats from the following
116 set are probably trivial at this point:
131 I have tested most of these in "generic" a.out configurations so I
132 feel pretty confident in them. If anything else works, it's an
135 Some ports now generate object files that are somewhat differently
136 shaped, but should be more correct. Specifically:
138 * Most a.out ports now sort the relocation table in numerically
139 ascending order. In previous versions of gas, the relocation table
140 was sorted in descending order. To get the previous functionality,
141 compile with -DREVERSE_SORT_RELOCS.
143 * ns32k: The last gas I have from hack simply looks broken for ns32k.
144 I think this one works, but don't have an assembler that I trust
145 against which to compare.
147 * i386: now uses ".align x" to mean x bytes rather than 2^x bytes. It
148 also pads with the noop instruction rather than zeroes.
150 In all cases, compiling with -DOLD_GAS will produce an assembler that
151 should produce object files that are bitwise identical to the previous
159 This isn't a complete catalog. I've forgotten what all has been done.
161 * support for i960, a29k, m88k, and tahoe.
163 * support for 68030 and 68040, including the ability to limit the
164 instructions that gas will accept. ie, you can assemble for EXACTLY
167 * object file formats have been broken out into separate backends.
169 * a new "backend" has been created to represent the target
170 environment. That is, gas now mimics various other assemblers
171 rather than creating it's own requirements. A side effect of this
172 is that this version of gas may not behave the same way as previous
175 * ansi. gas is now strictly ansi code so host ports should be
180 REPORTING BUGS IN GAS
183 Bugs in THIS RELEASE of gas should be reported directly to
184 rich@cygnus.com. NOT to bug-gnu-utils@prep.ai.mit.edu.
186 If you report a bug in GAS, please remember to include:
188 A description of exactly what went wrong.
190 How GAS was configured,
192 The Operating System GAS was running under.
194 The options given to GAS.
196 The actual input file that caused the problem.
198 It is silly to report a bug in GAS without including an input file for
199 GAS. Don't ask us to generate the file just because you made it from
200 files you think we have access to.
202 1. You might be mistaken.
203 2. It might take us a lot of time to install things to regenerate that file.
204 3. We might get a different file from the one you got, and might not see any
207 To save us these delays and uncertainties, always send the input file
208 for the program that failed.
210 If the input file is very large, and you are on the internet, you may
211 want to make it avaliable for anonymous FTP instead of mailing it. If you
212 do, include instructions for FTP'ing it in your bug report.