1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
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.
|
