First cut at sanitization, doc files, &c for gas/binutils releases
This commit is contained in:
parent
ea18081db6
commit
87ce76559c
10 changed files with 9195 additions and 0 deletions
1127
binutils/binutils.info
Normal file
1127
binutils/binutils.info
Normal file
File diff suppressed because it is too large
Load diff
241
gas/doc/as.info
Normal file
241
gas/doc/as.info
Normal file
|
@ -0,0 +1,241 @@
|
|||
This is Info file as.info, produced by Makeinfo-1.55 from the input
|
||||
file ./as.texinfo.
|
||||
|
||||
START-INFO-DIR-ENTRY
|
||||
* As:: The GNU assembler.
|
||||
END-INFO-DIR-ENTRY
|
||||
|
||||
This file documents the GNU Assembler "as".
|
||||
|
||||
Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of this
|
||||
manual provided the copyright notice and this permission notice are
|
||||
preserved on all copies.
|
||||
|
||||
Permission is granted to copy and distribute modified versions of
|
||||
this manual under the conditions for verbatim copying, provided also
|
||||
that the section entitled "GNU General Public License" is included
|
||||
exactly as in the original, and provided that the entire resulting
|
||||
derived work is distributed under the terms of a permission notice
|
||||
identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this
|
||||
manual into another language, under the above conditions for modified
|
||||
versions, except that the section entitled "GNU General Public License"
|
||||
may be included in a translation approved by the Free Software
|
||||
Foundation instead of in the original English.
|
||||
|
||||
|
||||
Indirect:
|
||||
as.info-1: 1145
|
||||
as.info-2: 50499
|
||||
as.info-3: 99245
|
||||
as.info-4: 149134
|
||||
as.info-5: 184796
|
||||
as.info-6: 203973
|
||||
|
||||
Tag Table:
|
||||
(Indirect)
|
||||
Node: Top1145
|
||||
Node: Overview1833
|
||||
Node: Manual5516
|
||||
Node: GNU Assembler6455
|
||||
Node: Object Formats7630
|
||||
Node: Command Line8077
|
||||
Node: Input Files9159
|
||||
Node: Object11067
|
||||
Node: Errors12012
|
||||
Node: Invoking13209
|
||||
Node: a14540
|
||||
Node: D15637
|
||||
Node: f15862
|
||||
Node: I16367
|
||||
Node: K16909
|
||||
Node: L17208
|
||||
Node: o17863
|
||||
Node: R18314
|
||||
Node: v19222
|
||||
Node: W19473
|
||||
Node: Syntax20045
|
||||
Node: Pre-processing20637
|
||||
Node: Whitespace22105
|
||||
Node: Comments22496
|
||||
Node: Symbol Intro24306
|
||||
Node: Statements24989
|
||||
Node: Constants27044
|
||||
Node: Characters27670
|
||||
Node: Strings28163
|
||||
Node: Chars30187
|
||||
Node: Numbers30928
|
||||
Node: Integers31459
|
||||
Node: Bignums32102
|
||||
Node: Flonums32445
|
||||
Node: Sections33977
|
||||
Node: Secs Background34340
|
||||
Node: Ld Sections38752
|
||||
Node: As Sections41141
|
||||
Node: Sub-Sections42031
|
||||
Node: bss45080
|
||||
Node: Symbols45664
|
||||
Node: Labels46311
|
||||
Node: Setting Symbols46735
|
||||
Node: Symbol Names47101
|
||||
Node: Dot50054
|
||||
Node: Symbol Attributes50499
|
||||
Node: Symbol Value51173
|
||||
Node: Symbol Type52207
|
||||
Node: a.out Symbols52586
|
||||
Node: Symbol Desc52836
|
||||
Node: Symbol Other53118
|
||||
Node: COFF Symbols53274
|
||||
Node: Expressions53883
|
||||
Node: Empty Exprs54214
|
||||
Node: Integer Exprs54559
|
||||
Node: Arguments54949
|
||||
Node: Operators56046
|
||||
Node: Prefix Ops56372
|
||||
Node: Infix Ops56691
|
||||
Node: Pseudo Ops58494
|
||||
Node: Abort61763
|
||||
Node: ABORT62164
|
||||
Node: Align62426
|
||||
Node: App-File63123
|
||||
Node: Ascii63660
|
||||
Node: Asciz63965
|
||||
Node: Byte64203
|
||||
Node: Comm64435
|
||||
Node: Data64992
|
||||
Node: Def65302
|
||||
Node: Desc65670
|
||||
Node: Dim66167
|
||||
Node: Double66558
|
||||
Node: Eject66889
|
||||
Node: Else67057
|
||||
Node: Endef67346
|
||||
Node: Endif67668
|
||||
Node: Equ67919
|
||||
Node: Extern68157
|
||||
Node: File68409
|
||||
Node: Fill69060
|
||||
Node: Float70017
|
||||
Node: Global70353
|
||||
Node: hword70895
|
||||
Node: Ident71216
|
||||
Node: If71516
|
||||
Node: Include72370
|
||||
Node: Int72910
|
||||
Node: Lcomm73288
|
||||
Node: Lflags73762
|
||||
Node: Line73949
|
||||
Node: Ln75003
|
||||
Node: List75147
|
||||
Node: Long75744
|
||||
Node: Nolist75915
|
||||
Node: Octa76332
|
||||
Node: Org76658
|
||||
Node: Psize77946
|
||||
Node: Quad78624
|
||||
Node: Sbttl79065
|
||||
Node: Scl79423
|
||||
Node: Section79922
|
||||
Node: Set80334
|
||||
Node: Short81059
|
||||
Node: Single81373
|
||||
Node: Size81710
|
||||
Node: Space82106
|
||||
Node: Stab82643
|
||||
Node: Tag84649
|
||||
Node: Text85155
|
||||
Node: Title85467
|
||||
Node: Type85839
|
||||
Node: Val86215
|
||||
Node: Word86570
|
||||
Node: Deprecated88443
|
||||
Node: Machine Dependencies88677
|
||||
Node: Vax-Dependent90020
|
||||
Node: Vax-Opts90528
|
||||
Node: VAX-float92810
|
||||
Node: VAX-directives93431
|
||||
Node: VAX-opcodes94280
|
||||
Node: VAX-branch94658
|
||||
Node: VAX-operands97159
|
||||
Node: VAX-no97895
|
||||
Node: AMD29K-Dependent98121
|
||||
Node: AMD29K Options98527
|
||||
Node: AMD29K Syntax98701
|
||||
Node: AMD29K-Chars98939
|
||||
Node: AMD29K-Regs99245
|
||||
Node: AMD29K Floating Point100509
|
||||
Node: AMD29K Directives100715
|
||||
Node: AMD29K Opcodes102123
|
||||
Node: H8/300-Dependent102459
|
||||
Node: H8/300 Options102865
|
||||
Node: H8/300 Syntax103046
|
||||
Node: H8/300-Chars103333
|
||||
Node: H8/300-Regs103617
|
||||
Node: H8/300-Addressing104521
|
||||
Node: H8/300 Floating Point105547
|
||||
Node: H8/300 Directives105863
|
||||
Node: H8/300 Opcodes106382
|
||||
Node: H8/500-Dependent114735
|
||||
Node: H8/500 Options115137
|
||||
Node: H8/500 Syntax115318
|
||||
Node: H8/500-Chars115605
|
||||
Node: H8/500-Regs115896
|
||||
Node: H8/500-Addressing116652
|
||||
Node: H8/500 Floating Point117269
|
||||
Node: H8/500 Directives117474
|
||||
Node: H8/500 Opcodes117793
|
||||
Node: SH-Dependent122906
|
||||
Node: SH Options123290
|
||||
Node: SH Syntax123455
|
||||
Node: SH-Chars123714
|
||||
Node: SH-Regs123993
|
||||
Node: SH-Addressing124592
|
||||
Node: SH Floating Point125486
|
||||
Node: SH Directives125671
|
||||
Node: SH Opcodes125876
|
||||
Node: i960-Dependent130123
|
||||
Node: Options-i960130513
|
||||
Node: Floating Point-i960134399
|
||||
Node: Directives-i960134656
|
||||
Node: Opcodes for i960136676
|
||||
Node: callj-i960137282
|
||||
Node: Compare-and-branch-i960137765
|
||||
Node: M68K-Dependent139652
|
||||
Node: M68K-Opts140107
|
||||
Node: M68K-Syntax141446
|
||||
Node: M68K-Moto-Syntax143276
|
||||
Node: M68K-Float144770
|
||||
Node: M68K-Directives145556
|
||||
Node: M68K-opcodes146094
|
||||
Node: M68K-Branch146306
|
||||
Node: M68K-Chars149134
|
||||
Node: Sparc-Dependent149489
|
||||
Node: Sparc-Opts149809
|
||||
Node: Sparc-Float150743
|
||||
Node: Sparc-Directives150925
|
||||
Node: i386-Dependent151975
|
||||
Node: i386-Options152570
|
||||
Node: i386-Syntax152714
|
||||
Node: i386-Opcodes154664
|
||||
Node: i386-Regs156783
|
||||
Node: i386-prefixes157924
|
||||
Node: i386-Memory159593
|
||||
Node: i386-jumps161871
|
||||
Node: i386-Float162987
|
||||
Node: i386-Notes164977
|
||||
Node: Z8000-Dependent165818
|
||||
Node: Z8000 Options166783
|
||||
Node: Z8000 Syntax166958
|
||||
Node: Z8000-Chars167234
|
||||
Node: Z8000-Regs167452
|
||||
Node: Z8000-Addressing168224
|
||||
Node: Z8000 Directives169167
|
||||
Node: Z8000 Opcodes170725
|
||||
Node: Acknowledgements180661
|
||||
Node: Copying184796
|
||||
Node: Index203973
|
||||
|
||||
End Tag Table
|
1320
gas/doc/as.info-1
Normal file
1320
gas/doc/as.info-1
Normal file
File diff suppressed because it is too large
Load diff
1524
gas/doc/as.info-2
Normal file
1524
gas/doc/as.info-2
Normal file
File diff suppressed because it is too large
Load diff
1454
gas/doc/as.info-3
Normal file
1454
gas/doc/as.info-3
Normal file
File diff suppressed because it is too large
Load diff
874
gas/doc/as.info-4
Normal file
874
gas/doc/as.info-4
Normal file
|
@ -0,0 +1,874 @@
|
|||
This is Info file as.info, produced by Makeinfo-1.55 from the input
|
||||
file ./as.texinfo.
|
||||
|
||||
START-INFO-DIR-ENTRY
|
||||
* As:: The GNU assembler.
|
||||
END-INFO-DIR-ENTRY
|
||||
|
||||
This file documents the GNU Assembler "as".
|
||||
|
||||
Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of this
|
||||
manual provided the copyright notice and this permission notice are
|
||||
preserved on all copies.
|
||||
|
||||
Permission is granted to copy and distribute modified versions of
|
||||
this manual under the conditions for verbatim copying, provided also
|
||||
that the section entitled "GNU General Public License" is included
|
||||
exactly as in the original, and provided that the entire resulting
|
||||
derived work is distributed under the terms of a permission notice
|
||||
identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this
|
||||
manual into another language, under the above conditions for modified
|
||||
versions, except that the section entitled "GNU General Public License"
|
||||
may be included in a translation approved by the Free Software
|
||||
Foundation instead of in the original English.
|
||||
|
||||
|
||||
File: as.info, Node: M68K-Chars, Prev: M68K-Branch, Up: M68K-opcodes
|
||||
|
||||
Special Characters
|
||||
..................
|
||||
|
||||
The immediate character is `#' for Sun compatibility. The
|
||||
line-comment character is `|'. If a `#' appears at the beginning of a
|
||||
line, it is treated as a comment unless it looks like `# line file', in
|
||||
which case it is treated normally.
|
||||
|
||||
|
||||
File: as.info, Node: Sparc-Dependent, Next: Z8000-Dependent, Prev: M68K-Dependent, Up: Machine Dependencies
|
||||
|
||||
SPARC Dependent Features
|
||||
========================
|
||||
|
||||
* Menu:
|
||||
|
||||
* Sparc-Opts:: Options
|
||||
* Sparc-Float:: Floating Point
|
||||
* Sparc-Directives:: Sparc Machine Directives
|
||||
|
||||
|
||||
File: as.info, Node: Sparc-Opts, Next: Sparc-Float, Up: Sparc-Dependent
|
||||
|
||||
Options
|
||||
-------
|
||||
|
||||
The SPARC chip family includes several successive levels (or other
|
||||
variants) of chip, using the same core instruction set, but including a
|
||||
few additional instructions at each level.
|
||||
|
||||
By default, `as' assumes the core instruction set (SPARC v6), but
|
||||
"bumps" the architecture level as needed: it switches to successively
|
||||
higher architectures as it encounters instructions that only exist in
|
||||
the higher levels.
|
||||
|
||||
`-Av6 | -Av7 | -Av8 | -Asparclite'
|
||||
Use one of the `-A' options to select one of the SPARC
|
||||
architectures explicitly. If you select an architecture
|
||||
explicitly, `as' reports a fatal error if it encounters an
|
||||
instruction or feature requiring a higher level.
|
||||
|
||||
`-bump'
|
||||
Permit the assembler to "bump" the architecture level as required,
|
||||
but warn whenever it is necessary to switch to another level.
|
||||
|
||||
|
||||
File: as.info, Node: Sparc-Float, Next: Sparc-Directives, Prev: Sparc-Opts, Up: Sparc-Dependent
|
||||
|
||||
Floating Point
|
||||
--------------
|
||||
|
||||
The Sparc uses IEEE floating-point numbers.
|
||||
|
||||
|
||||
File: as.info, Node: Sparc-Directives, Prev: Sparc-Float, Up: Sparc-Dependent
|
||||
|
||||
Sparc Machine Directives
|
||||
------------------------
|
||||
|
||||
The Sparc version of `as' supports the following additional machine
|
||||
directives:
|
||||
|
||||
`.common'
|
||||
This must be followed by a symbol name, a positive number, and
|
||||
`"bss"'. This behaves somewhat like `.comm', but the syntax is
|
||||
different.
|
||||
|
||||
`.half'
|
||||
This is functionally identical to `.short'.
|
||||
|
||||
`.proc'
|
||||
This directive is ignored. Any text following it on the same line
|
||||
is also ignored.
|
||||
|
||||
`.reserve'
|
||||
This must be followed by a symbol name, a positive number, and
|
||||
`"bss"'. This behaves somewhat like `.lcomm', but the syntax is
|
||||
different.
|
||||
|
||||
`.seg'
|
||||
This must be followed by `"text"', `"data"', or `"data1"'. It
|
||||
behaves like `.text', `.data', or `.data 1'.
|
||||
|
||||
`.skip'
|
||||
This is functionally identical to the `.space' directive.
|
||||
|
||||
`.word'
|
||||
On the Sparc, the .word directive produces 32 bit values, instead
|
||||
of the 16 bit values it produces on many other machines.
|
||||
|
||||
|
||||
File: as.info, Node: i386-Dependent, Prev: Z8000-Dependent, Up: Machine Dependencies
|
||||
|
||||
80386 Dependent Features
|
||||
========================
|
||||
|
||||
* Menu:
|
||||
|
||||
* i386-Options:: Options
|
||||
* i386-Syntax:: AT&T Syntax versus Intel Syntax
|
||||
* i386-Opcodes:: Opcode Naming
|
||||
* i386-Regs:: Register Naming
|
||||
* i386-prefixes:: Opcode Prefixes
|
||||
* i386-Memory:: Memory References
|
||||
* i386-jumps:: Handling of Jump Instructions
|
||||
* i386-Float:: Floating Point
|
||||
* i386-Notes:: Notes
|
||||
|
||||
|
||||
File: as.info, Node: i386-Options, Next: i386-Syntax, Up: i386-Dependent
|
||||
|
||||
Options
|
||||
-------
|
||||
|
||||
The 80386 has no machine dependent options.
|
||||
|
||||
|
||||
File: as.info, Node: i386-Syntax, Next: i386-Opcodes, Prev: i386-Options, Up: i386-Dependent
|
||||
|
||||
AT&T Syntax versus Intel Syntax
|
||||
-------------------------------
|
||||
|
||||
In order to maintain compatibility with the output of `gcc', `as'
|
||||
supports AT&T System V/386 assembler syntax. This is quite different
|
||||
from Intel syntax. We mention these differences because almost all
|
||||
80386 documents used only Intel syntax. Notable differences between
|
||||
the two syntaxes are:
|
||||
|
||||
* AT&T immediate operands are preceded by `$'; Intel immediate
|
||||
operands are undelimited (Intel `push 4' is AT&T `pushl $4').
|
||||
AT&T register operands are preceded by `%'; Intel register operands
|
||||
are undelimited. AT&T absolute (as opposed to PC relative)
|
||||
jump/call operands are prefixed by `*'; they are undelimited in
|
||||
Intel syntax.
|
||||
|
||||
* AT&T and Intel syntax use the opposite order for source and
|
||||
destination operands. Intel `add eax, 4' is `addl $4, %eax'. The
|
||||
`source, dest' convention is maintained for compatibility with
|
||||
previous Unix assemblers.
|
||||
|
||||
* In AT&T syntax the size of memory operands is determined from the
|
||||
last character of the opcode name. Opcode suffixes of `b', `w',
|
||||
and `l' specify byte (8-bit), word (16-bit), and long (32-bit)
|
||||
memory references. Intel syntax accomplishes this by prefixes
|
||||
memory operands (*not* the opcodes themselves) with `byte ptr',
|
||||
`word ptr', and `dword ptr'. Thus, Intel `mov al, byte ptr FOO'
|
||||
is `movb FOO, %al' in AT&T syntax.
|
||||
|
||||
* Immediate form long jumps and calls are `lcall/ljmp $SECTION,
|
||||
$OFFSET' in AT&T syntax; the Intel syntax is `call/jmp far
|
||||
SECTION:OFFSET'. Also, the far return instruction is `lret
|
||||
$STACK-ADJUST' in AT&T syntax; Intel syntax is `ret far
|
||||
STACK-ADJUST'.
|
||||
|
||||
* The AT&T assembler does not provide support for multiple section
|
||||
programs. Unix style systems expect all programs to be single
|
||||
sections.
|
||||
|
||||
|
||||
File: as.info, Node: i386-Opcodes, Next: i386-Regs, Prev: i386-Syntax, Up: i386-Dependent
|
||||
|
||||
Opcode Naming
|
||||
-------------
|
||||
|
||||
Opcode names are suffixed with one character modifiers which specify
|
||||
the size of operands. The letters `b', `w', and `l' specify byte,
|
||||
word, and long operands. If no suffix is specified by an instruction
|
||||
and it contains no memory operands then `as' tries to fill in the
|
||||
missing suffix based on the destination register operand (the last one
|
||||
by convention). Thus, `mov %ax, %bx' is equivalent to `movw %ax, %bx';
|
||||
also, `mov $1, %bx' is equivalent to `movw $1, %bx'. Note that this is
|
||||
incompatible with the AT&T Unix assembler which assumes that a missing
|
||||
opcode suffix implies long operand size. (This incompatibility does
|
||||
not affect compiler output since compilers always explicitly specify
|
||||
the opcode suffix.)
|
||||
|
||||
Almost all opcodes have the same names in AT&T and Intel format.
|
||||
There are a few exceptions. The sign extend and zero extend
|
||||
instructions need two sizes to specify them. They need a size to
|
||||
sign/zero extend *from* and a size to zero extend *to*. This is
|
||||
accomplished by using two opcode suffixes in AT&T syntax. Base names
|
||||
for sign extend and zero extend are `movs...' and `movz...' in AT&T
|
||||
syntax (`movsx' and `movzx' in Intel syntax). The opcode suffixes are
|
||||
tacked on to this base name, the *from* suffix before the *to* suffix.
|
||||
Thus, `movsbl %al, %edx' is AT&T syntax for "move sign extend *from*
|
||||
%al *to* %edx." Possible suffixes, thus, are `bl' (from byte to long),
|
||||
`bw' (from byte to word), and `wl' (from word to long).
|
||||
|
||||
The Intel-syntax conversion instructions
|
||||
|
||||
* `cbw' -- sign-extend byte in `%al' to word in `%ax',
|
||||
|
||||
* `cwde' -- sign-extend word in `%ax' to long in `%eax',
|
||||
|
||||
* `cwd' -- sign-extend word in `%ax' to long in `%dx:%ax',
|
||||
|
||||
* `cdq' -- sign-extend dword in `%eax' to quad in `%edx:%eax',
|
||||
|
||||
are called `cbtw', `cwtl', `cwtd', and `cltd' in AT&T naming. `as'
|
||||
accepts either naming for these instructions.
|
||||
|
||||
Far call/jump instructions are `lcall' and `ljmp' in AT&T syntax,
|
||||
but are `call far' and `jump far' in Intel convention.
|
||||
|
||||
|
||||
File: as.info, Node: i386-Regs, Next: i386-prefixes, Prev: i386-Opcodes, Up: i386-Dependent
|
||||
|
||||
Register Naming
|
||||
---------------
|
||||
|
||||
Register operands are always prefixes with `%'. The 80386 registers
|
||||
consist of
|
||||
|
||||
* the 8 32-bit registers `%eax' (the accumulator), `%ebx', `%ecx',
|
||||
`%edx', `%edi', `%esi', `%ebp' (the frame pointer), and `%esp'
|
||||
(the stack pointer).
|
||||
|
||||
* the 8 16-bit low-ends of these: `%ax', `%bx', `%cx', `%dx', `%di',
|
||||
`%si', `%bp', and `%sp'.
|
||||
|
||||
* the 8 8-bit registers: `%ah', `%al', `%bh', `%bl', `%ch', `%cl',
|
||||
`%dh', and `%dl' (These are the high-bytes and low-bytes of `%ax',
|
||||
`%bx', `%cx', and `%dx')
|
||||
|
||||
* the 6 section registers `%cs' (code section), `%ds' (data
|
||||
section), `%ss' (stack section), `%es', `%fs', and `%gs'.
|
||||
|
||||
* the 3 processor control registers `%cr0', `%cr2', and `%cr3'.
|
||||
|
||||
* the 6 debug registers `%db0', `%db1', `%db2', `%db3', `%db6', and
|
||||
`%db7'.
|
||||
|
||||
* the 2 test registers `%tr6' and `%tr7'.
|
||||
|
||||
* the 8 floating point register stack `%st' or equivalently
|
||||
`%st(0)', `%st(1)', `%st(2)', `%st(3)', `%st(4)', `%st(5)',
|
||||
`%st(6)', and `%st(7)'.
|
||||
|
||||
|
||||
File: as.info, Node: i386-prefixes, Next: i386-Memory, Prev: i386-Regs, Up: i386-Dependent
|
||||
|
||||
Opcode Prefixes
|
||||
---------------
|
||||
|
||||
Opcode prefixes are used to modify the following opcode. They are
|
||||
used to repeat string instructions, to provide section overrides, to
|
||||
perform bus lock operations, and to give operand and address size
|
||||
(16-bit operands are specified in an instruction by prefixing what would
|
||||
normally be 32-bit operands with a "operand size" opcode prefix).
|
||||
Opcode prefixes are usually given as single-line instructions with no
|
||||
operands, and must directly precede the instruction they act upon. For
|
||||
example, the `scas' (scan string) instruction is repeated with:
|
||||
repne
|
||||
scas
|
||||
|
||||
Here is a list of opcode prefixes:
|
||||
|
||||
* Section override prefixes `cs', `ds', `ss', `es', `fs', `gs'.
|
||||
These are automatically added by specifying using the
|
||||
SECTION:MEMORY-OPERAND form for memory references.
|
||||
|
||||
* Operand/Address size prefixes `data16' and `addr16' change 32-bit
|
||||
operands/addresses into 16-bit operands/addresses. Note that
|
||||
16-bit addressing modes (i.e. 8086 and 80286 addressing modes) are
|
||||
not supported (yet).
|
||||
|
||||
* The bus lock prefix `lock' inhibits interrupts during execution of
|
||||
the instruction it precedes. (This is only valid with certain
|
||||
instructions; see a 80386 manual for details).
|
||||
|
||||
* The wait for coprocessor prefix `wait' waits for the coprocessor
|
||||
to complete the current instruction. This should never be needed
|
||||
for the 80386/80387 combination.
|
||||
|
||||
* The `rep', `repe', and `repne' prefixes are added to string
|
||||
instructions to make them repeat `%ecx' times.
|
||||
|
||||
|
||||
File: as.info, Node: i386-Memory, Next: i386-jumps, Prev: i386-prefixes, Up: i386-Dependent
|
||||
|
||||
Memory References
|
||||
-----------------
|
||||
|
||||
An Intel syntax indirect memory reference of the form
|
||||
|
||||
SECTION:[BASE + INDEX*SCALE + DISP]
|
||||
|
||||
is translated into the AT&T syntax
|
||||
|
||||
SECTION:DISP(BASE, INDEX, SCALE)
|
||||
|
||||
where BASE and INDEX are the optional 32-bit base and index registers,
|
||||
DISP is the optional displacement, and SCALE, taking the values 1, 2,
|
||||
4, and 8, multiplies INDEX to calculate the address of the operand. If
|
||||
no SCALE is specified, SCALE is taken to be 1. SECTION specifies the
|
||||
optional section register for the memory operand, and may override the
|
||||
default section register (see a 80386 manual for section register
|
||||
defaults). Note that section overrides in AT&T syntax *must* have be
|
||||
preceded by a `%'. If you specify a section override which coincides
|
||||
with the default section register, `as' will *not* output any section
|
||||
register override prefixes to assemble the given instruction. Thus,
|
||||
section overrides can be specified to emphasize which section register
|
||||
is used for a given memory operand.
|
||||
|
||||
Here are some examples of Intel and AT&T style memory references:
|
||||
|
||||
AT&T: `-4(%ebp)', Intel: `[ebp - 4]'
|
||||
BASE is `%ebp'; DISP is `-4'. SECTION is missing, and the default
|
||||
section is used (`%ss' for addressing with `%ebp' as the base
|
||||
register). INDEX, SCALE are both missing.
|
||||
|
||||
AT&T: `foo(,%eax,4)', Intel: `[foo + eax*4]'
|
||||
INDEX is `%eax' (scaled by a SCALE 4); DISP is `foo'. All other
|
||||
fields are missing. The section register here defaults to `%ds'.
|
||||
|
||||
AT&T: `foo(,1)'; Intel `[foo]'
|
||||
This uses the value pointed to by `foo' as a memory operand. Note
|
||||
that BASE and INDEX are both missing, but there is only *one* `,'.
|
||||
This is a syntactic exception.
|
||||
|
||||
AT&T: `%gs:foo'; Intel `gs:foo'
|
||||
This selects the contents of the variable `foo' with section
|
||||
register SECTION being `%gs'.
|
||||
|
||||
Absolute (as opposed to PC relative) call and jump operands must be
|
||||
prefixed with `*'. If no `*' is specified, `as' will always choose PC
|
||||
relative addressing for jump/call labels.
|
||||
|
||||
Any instruction that has a memory operand *must* specify its size
|
||||
(byte, word, or long) with an opcode suffix (`b', `w', or `l',
|
||||
respectively).
|
||||
|
||||
|
||||
File: as.info, Node: i386-jumps, Next: i386-Float, Prev: i386-Memory, Up: i386-Dependent
|
||||
|
||||
Handling of Jump Instructions
|
||||
-----------------------------
|
||||
|
||||
Jump instructions are always optimized to use the smallest possible
|
||||
displacements. This is accomplished by using byte (8-bit) displacement
|
||||
jumps whenever the target is sufficiently close. If a byte displacement
|
||||
is insufficient a long (32-bit) displacement is used. We do not support
|
||||
word (16-bit) displacement jumps (i.e. prefixing the jump instruction
|
||||
with the `addr16' opcode prefix), since the 80386 insists upon masking
|
||||
`%eip' to 16 bits after the word displacement is added.
|
||||
|
||||
Note that the `jcxz', `jecxz', `loop', `loopz', `loope', `loopnz'
|
||||
and `loopne' instructions only come in byte displacements, so that it
|
||||
is possible that use of these instructions (`gcc' does not use them)
|
||||
will cause the assembler to print an error message (and generate
|
||||
incorrect code). The AT&T 80386 assembler tries to get around this
|
||||
problem by expanding `jcxz foo' to
|
||||
jcxz cx_zero
|
||||
jmp cx_nonzero
|
||||
cx_zero: jmp foo
|
||||
cx_nonzero:
|
||||
|
||||
|
||||
File: as.info, Node: i386-Float, Next: i386-Notes, Prev: i386-jumps, Up: i386-Dependent
|
||||
|
||||
Floating Point
|
||||
--------------
|
||||
|
||||
All 80387 floating point types except packed BCD are supported.
|
||||
(BCD support may be added without much difficulty). These data types
|
||||
are 16-, 32-, and 64- bit integers, and single (32-bit), double
|
||||
(64-bit), and extended (80-bit) precision floating point. Each
|
||||
supported type has an opcode suffix and a constructor associated with
|
||||
it. Opcode suffixes specify operand's data types. Constructors build
|
||||
these data types into memory.
|
||||
|
||||
* Floating point constructors are `.float' or `.single', `.double',
|
||||
and `.tfloat' for 32-, 64-, and 80-bit formats. These correspond
|
||||
to opcode suffixes `s', `l', and `t'. `t' stands for temporary
|
||||
real, and that the 80387 only supports this format via the `fldt'
|
||||
(load temporary real to stack top) and `fstpt' (store temporary
|
||||
real and pop stack) instructions.
|
||||
|
||||
* Integer constructors are `.word', `.long' or `.int', and `.quad'
|
||||
for the 16-, 32-, and 64-bit integer formats. The corresponding
|
||||
opcode suffixes are `s' (single), `l' (long), and `q' (quad). As
|
||||
with the temporary real format the 64-bit `q' format is only
|
||||
present in the `fildq' (load quad integer to stack top) and
|
||||
`fistpq' (store quad integer and pop stack) instructions.
|
||||
|
||||
Register to register operations do not require opcode suffixes, so
|
||||
that `fst %st, %st(1)' is equivalent to `fstl %st, %st(1)'.
|
||||
|
||||
Since the 80387 automatically synchronizes with the 80386 `fwait'
|
||||
instructions are almost never needed (this is not the case for the
|
||||
80286/80287 and 8086/8087 combinations). Therefore, `as' suppresses
|
||||
the `fwait' instruction whenever it is implicitly selected by one of
|
||||
the `fn...' instructions. For example, `fsave' and `fnsave' are
|
||||
treated identically. In general, all the `fn...' instructions are made
|
||||
equivalent to `f...' instructions. If `fwait' is desired it must be
|
||||
explicitly coded.
|
||||
|
||||
|
||||
File: as.info, Node: i386-Notes, Prev: i386-Float, Up: i386-Dependent
|
||||
|
||||
Notes
|
||||
-----
|
||||
|
||||
There is some trickery concerning the `mul' and `imul' instructions
|
||||
that deserves mention. The 16-, 32-, and 64-bit expanding multiplies
|
||||
(base opcode `0xf6'; extension 4 for `mul' and 5 for `imul') can be
|
||||
output only in the one operand form. Thus, `imul %ebx, %eax' does
|
||||
*not* select the expanding multiply; the expanding multiply would
|
||||
clobber the `%edx' register, and this would confuse `gcc' output. Use
|
||||
`imul %ebx' to get the 64-bit product in `%edx:%eax'.
|
||||
|
||||
We have added a two operand form of `imul' when the first operand is
|
||||
an immediate mode expression and the second operand is a register.
|
||||
This is just a shorthand, so that, multiplying `%eax' by 69, for
|
||||
example, can be done with `imul $69, %eax' rather than `imul $69, %eax,
|
||||
%eax'.
|
||||
|
||||
|
||||
File: as.info, Node: Z8000-Dependent, Next: i386-Dependent, Prev: Sparc-Dependent, Up: Machine Dependencies
|
||||
|
||||
Z8000 Dependent Features
|
||||
========================
|
||||
|
||||
The Z8000 as supports both members of the Z8000 family: the
|
||||
unsegmented Z8002, with 16 bit addresses, and the segmented Z8001 with
|
||||
24 bit addresses.
|
||||
|
||||
When the assembler is in unsegmented mode (specified with the
|
||||
`unsegm' directive), an address will take up one word (16 bit) sized
|
||||
register. When the assembler is in segmented mode (specified with the
|
||||
`segm' directive), a 24-bit address takes up a long (32 bit) register.
|
||||
*Note Assembler Directives for the Z8000: Z8000 Directives, for a list
|
||||
of other Z8000 specific assembler directives.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Z8000 Options:: No special command-line options for Z8000
|
||||
* Z8000 Syntax:: Assembler syntax for the Z8000
|
||||
* Z8000 Directives:: Special directives for the Z8000
|
||||
* Z8000 Opcodes:: Opcodes
|
||||
|
||||
|
||||
File: as.info, Node: Z8000 Options, Next: Z8000 Syntax, Up: Z8000-Dependent
|
||||
|
||||
Options
|
||||
-------
|
||||
|
||||
`as' has no additional command-line options for the Zilog Z8000
|
||||
family.
|
||||
|
||||
|
||||
File: as.info, Node: Z8000 Syntax, Next: Z8000 Directives, Prev: Z8000 Options, Up: Z8000-Dependent
|
||||
|
||||
Syntax
|
||||
------
|
||||
|
||||
* Menu:
|
||||
|
||||
* Z8000-Chars:: Special Characters
|
||||
* Z8000-Regs:: Register Names
|
||||
* Z8000-Addressing:: Addressing Modes
|
||||
|
||||
|
||||
File: as.info, Node: Z8000-Chars, Next: Z8000-Regs, Up: Z8000 Syntax
|
||||
|
||||
Special Characters
|
||||
..................
|
||||
|
||||
`!' is the line comment character.
|
||||
|
||||
You can use `;' instead of a newline to separate statements.
|
||||
|
||||
|
||||
File: as.info, Node: Z8000-Regs, Next: Z8000-Addressing, Prev: Z8000-Chars, Up: Z8000 Syntax
|
||||
|
||||
Register Names
|
||||
..............
|
||||
|
||||
The Z8000 has sixteen 16 bit registers, numbered 0 to 15. You can
|
||||
refer to different sized groups of registers by register number, with
|
||||
the prefix `r' for 16 bit registers, `rr' for 32 bit registers and `rq'
|
||||
for 64 bit registers. You can also refer to the contents of the first
|
||||
eight (of the sixteen 16 bit registers) by bytes. They are named `rNh'
|
||||
and `rNl'.
|
||||
|
||||
*byte registers*
|
||||
r0l r0h r1h r1l r2h r2l r3h r3l
|
||||
r4h r4l r5h r5l r6h r6l r7h r7l
|
||||
*word registers*
|
||||
r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15
|
||||
*long word registers*
|
||||
rr0 rr2 rr4 rr6 rr8 rr10 rr12 rr14
|
||||
*quad word registers*
|
||||
rq0 rq4 rq8 rq12
|
||||
|
||||
|
||||
File: as.info, Node: Z8000-Addressing, Prev: Z8000-Regs, Up: Z8000 Syntax
|
||||
|
||||
Addressing Modes
|
||||
................
|
||||
|
||||
as understands the following addressing modes for the Z8000:
|
||||
|
||||
`rN'
|
||||
Register direct
|
||||
|
||||
`@rN'
|
||||
Indirect register
|
||||
|
||||
`ADDR'
|
||||
Direct: the 16 bit or 24 bit address (depending on whether the
|
||||
assembler is in segmented or unsegmented mode) of the operand is
|
||||
in the instruction.
|
||||
|
||||
`address(rN)'
|
||||
Indexed: the 16 or 24 bit address is added to the 16 bit register
|
||||
to produce the final address in memory of the operand.
|
||||
|
||||
`rN(#IMM)'
|
||||
Base Address: the 16 or 24 bit register is added to the 16 bit sign
|
||||
extended immediate displacement to produce the final address in
|
||||
memory of the operand.
|
||||
|
||||
`rN(rM)'
|
||||
Base Index: the 16 or 24 bit register rN is added to the sign
|
||||
extended 16 bit index register rM to produce the final address in
|
||||
memory of the operand.
|
||||
|
||||
`#XX'
|
||||
Immediate data XX.
|
||||
|
||||
|
||||
File: as.info, Node: Z8000 Directives, Next: Z8000 Opcodes, Prev: Z8000 Syntax, Up: Z8000-Dependent
|
||||
|
||||
Assembler Directives for the Z8000
|
||||
----------------------------------
|
||||
|
||||
The Z8000 port of as includes these additional assembler directives,
|
||||
for compatibility with other Z8000 assemblers. As shown, these do not
|
||||
begin with `.' (unlike the ordinary as directives).
|
||||
|
||||
`segm'
|
||||
Generates code for the segmented Z8001.
|
||||
|
||||
`unsegm'
|
||||
Generates code for the unsegmented Z8002.
|
||||
|
||||
`name'
|
||||
Synonym for `.file'
|
||||
|
||||
`global'
|
||||
Synonum for `.global'
|
||||
|
||||
`wval'
|
||||
Synonym for `.word'
|
||||
|
||||
`lval'
|
||||
Synonym for `.long'
|
||||
|
||||
`bval'
|
||||
Synonym for `.byte'
|
||||
|
||||
`sval'
|
||||
Assemble a string. `sval' expects one string literal, delimited by
|
||||
single quotes. It assembles each byte of the string into
|
||||
consecutive addresses. You can use the escape sequence `%XX'
|
||||
(where XX represents a two-digit hexadecimal number) to represent
|
||||
the character whose ASCII value is XX. Use this feature to
|
||||
describe single quote and other characters that may not appear in
|
||||
string literals as themselves. For example, the C statement
|
||||
`char *a = "he said \"it's 50% off\"";' is represented in Z8000
|
||||
assembly language (shown with the assembler output in hex at the
|
||||
left) as
|
||||
|
||||
68652073 sval 'he said %22it%27s 50%25 off%22%00'
|
||||
61696420
|
||||
22697427
|
||||
73203530
|
||||
25206F66
|
||||
662200
|
||||
|
||||
`rsect'
|
||||
synonym for `.section'
|
||||
|
||||
`block'
|
||||
synonym for `.space'
|
||||
|
||||
`even'
|
||||
synonym for `.align 1'
|
||||
|
||||
|
||||
File: as.info, Node: Z8000 Opcodes, Prev: Z8000 Directives, Up: Z8000-Dependent
|
||||
|
||||
Opcodes
|
||||
-------
|
||||
|
||||
For detailed information on the Z8000 machine instruction set, see
|
||||
`Z8000 Technical Manual'.
|
||||
|
||||
The following table summarizes the opcodes and their arguments:
|
||||
|
||||
rs 16 bit source register
|
||||
rd 16 bit destination register
|
||||
rbs 8 bit source register
|
||||
rbd 8 bit destination register
|
||||
rrs 32 bit source register
|
||||
rrd 32 bit destination register
|
||||
rqs 64 bit source register
|
||||
rqd 64 bit destination register
|
||||
addr 16/24 bit address
|
||||
imm immediate data
|
||||
|
||||
adc rd,rs clrb addr cpsir @rd,@rs,rr,cc
|
||||
adcb rbd,rbs clrb addr(rd) cpsirb @rd,@rs,rr,cc
|
||||
add rd,@rs clrb rbd dab rbd
|
||||
add rd,addr com @rd dbjnz rbd,disp7
|
||||
add rd,addr(rs) com addr dec @rd,imm4m1
|
||||
add rd,imm16 com addr(rd) dec addr(rd),imm4m1
|
||||
add rd,rs com rd dec addr,imm4m1
|
||||
addb rbd,@rs comb @rd dec rd,imm4m1
|
||||
addb rbd,addr comb addr decb @rd,imm4m1
|
||||
addb rbd,addr(rs) comb addr(rd) decb addr(rd),imm4m1
|
||||
addb rbd,imm8 comb rbd decb addr,imm4m1
|
||||
addb rbd,rbs comflg flags decb rbd,imm4m1
|
||||
addl rrd,@rs cp @rd,imm16 di i2
|
||||
addl rrd,addr cp addr(rd),imm16 div rrd,@rs
|
||||
addl rrd,addr(rs) cp addr,imm16 div rrd,addr
|
||||
addl rrd,imm32 cp rd,@rs div rrd,addr(rs)
|
||||
addl rrd,rrs cp rd,addr div rrd,imm16
|
||||
and rd,@rs cp rd,addr(rs) div rrd,rs
|
||||
and rd,addr cp rd,imm16 divl rqd,@rs
|
||||
and rd,addr(rs) cp rd,rs divl rqd,addr
|
||||
and rd,imm16 cpb @rd,imm8 divl rqd,addr(rs)
|
||||
and rd,rs cpb addr(rd),imm8 divl rqd,imm32
|
||||
andb rbd,@rs cpb addr,imm8 divl rqd,rrs
|
||||
andb rbd,addr cpb rbd,@rs djnz rd,disp7
|
||||
andb rbd,addr(rs) cpb rbd,addr ei i2
|
||||
andb rbd,imm8 cpb rbd,addr(rs) ex rd,@rs
|
||||
andb rbd,rbs cpb rbd,imm8 ex rd,addr
|
||||
bit @rd,imm4 cpb rbd,rbs ex rd,addr(rs)
|
||||
bit addr(rd),imm4 cpd rd,@rs,rr,cc ex rd,rs
|
||||
bit addr,imm4 cpdb rbd,@rs,rr,cc exb rbd,@rs
|
||||
bit rd,imm4 cpdr rd,@rs,rr,cc exb rbd,addr
|
||||
bit rd,rs cpdrb rbd,@rs,rr,cc exb rbd,addr(rs)
|
||||
bitb @rd,imm4 cpi rd,@rs,rr,cc exb rbd,rbs
|
||||
bitb addr(rd),imm4 cpib rbd,@rs,rr,cc ext0e imm8
|
||||
bitb addr,imm4 cpir rd,@rs,rr,cc ext0f imm8
|
||||
bitb rbd,imm4 cpirb rbd,@rs,rr,cc ext8e imm8
|
||||
bitb rbd,rs cpl rrd,@rs ext8f imm8
|
||||
bpt cpl rrd,addr exts rrd
|
||||
call @rd cpl rrd,addr(rs) extsb rd
|
||||
call addr cpl rrd,imm32 extsl rqd
|
||||
call addr(rd) cpl rrd,rrs halt
|
||||
calr disp12 cpsd @rd,@rs,rr,cc in rd,@rs
|
||||
clr @rd cpsdb @rd,@rs,rr,cc in rd,imm16
|
||||
clr addr cpsdr @rd,@rs,rr,cc inb rbd,@rs
|
||||
clr addr(rd) cpsdrb @rd,@rs,rr,cc inb rbd,imm16
|
||||
clr rd cpsi @rd,@rs,rr,cc inc @rd,imm4m1
|
||||
clrb @rd cpsib @rd,@rs,rr,cc inc addr(rd),imm4m1
|
||||
inc addr,imm4m1 ldb rbd,rs(rx) mult rrd,addr(rs)
|
||||
inc rd,imm4m1 ldb rd(imm16),rbs mult rrd,imm16
|
||||
incb @rd,imm4m1 ldb rd(rx),rbs mult rrd,rs
|
||||
incb addr(rd),imm4m1 ldctl ctrl,rs multl rqd,@rs
|
||||
incb addr,imm4m1 ldctl rd,ctrl multl rqd,addr
|
||||
incb rbd,imm4m1 ldd @rs,@rd,rr multl rqd,addr(rs)
|
||||
ind @rd,@rs,ra lddb @rs,@rd,rr multl rqd,imm32
|
||||
indb @rd,@rs,rba lddr @rs,@rd,rr multl rqd,rrs
|
||||
inib @rd,@rs,ra lddrb @rs,@rd,rr neg @rd
|
||||
inibr @rd,@rs,ra ldi @rd,@rs,rr neg addr
|
||||
iret ldib @rd,@rs,rr neg addr(rd)
|
||||
jp cc,@rd ldir @rd,@rs,rr neg rd
|
||||
jp cc,addr ldirb @rd,@rs,rr negb @rd
|
||||
jp cc,addr(rd) ldk rd,imm4 negb addr
|
||||
jr cc,disp8 ldl @rd,rrs negb addr(rd)
|
||||
ld @rd,imm16 ldl addr(rd),rrs negb rbd
|
||||
ld @rd,rs ldl addr,rrs nop
|
||||
ld addr(rd),imm16 ldl rd(imm16),rrs or rd,@rs
|
||||
ld addr(rd),rs ldl rd(rx),rrs or rd,addr
|
||||
ld addr,imm16 ldl rrd,@rs or rd,addr(rs)
|
||||
ld addr,rs ldl rrd,addr or rd,imm16
|
||||
ld rd(imm16),rs ldl rrd,addr(rs) or rd,rs
|
||||
ld rd(rx),rs ldl rrd,imm32 orb rbd,@rs
|
||||
ld rd,@rs ldl rrd,rrs orb rbd,addr
|
||||
ld rd,addr ldl rrd,rs(imm16) orb rbd,addr(rs)
|
||||
ld rd,addr(rs) ldl rrd,rs(rx) orb rbd,imm8
|
||||
ld rd,imm16 ldm @rd,rs,n orb rbd,rbs
|
||||
ld rd,rs ldm addr(rd),rs,n out @rd,rs
|
||||
ld rd,rs(imm16) ldm addr,rs,n out imm16,rs
|
||||
ld rd,rs(rx) ldm rd,@rs,n outb @rd,rbs
|
||||
lda rd,addr ldm rd,addr(rs),n outb imm16,rbs
|
||||
lda rd,addr(rs) ldm rd,addr,n outd @rd,@rs,ra
|
||||
lda rd,rs(imm16) ldps @rs outdb @rd,@rs,rba
|
||||
lda rd,rs(rx) ldps addr outib @rd,@rs,ra
|
||||
ldar rd,disp16 ldps addr(rs) outibr @rd,@rs,ra
|
||||
ldb @rd,imm8 ldr disp16,rs pop @rd,@rs
|
||||
ldb @rd,rbs ldr rd,disp16 pop addr(rd),@rs
|
||||
ldb addr(rd),imm8 ldrb disp16,rbs pop addr,@rs
|
||||
ldb addr(rd),rbs ldrb rbd,disp16 pop rd,@rs
|
||||
ldb addr,imm8 ldrl disp16,rrs popl @rd,@rs
|
||||
ldb addr,rbs ldrl rrd,disp16 popl addr(rd),@rs
|
||||
ldb rbd,@rs mbit popl addr,@rs
|
||||
ldb rbd,addr mreq rd popl rrd,@rs
|
||||
ldb rbd,addr(rs) mres push @rd,@rs
|
||||
ldb rbd,imm8 mset push @rd,addr
|
||||
ldb rbd,rbs mult rrd,@rs push @rd,addr(rs)
|
||||
ldb rbd,rs(imm16) mult rrd,addr push @rd,imm16
|
||||
push @rd,rs set addr,imm4 subl rrd,imm32
|
||||
pushl @rd,@rs set rd,imm4 subl rrd,rrs
|
||||
pushl @rd,addr set rd,rs tcc cc,rd
|
||||
pushl @rd,addr(rs) setb @rd,imm4 tccb cc,rbd
|
||||
pushl @rd,rrs setb addr(rd),imm4 test @rd
|
||||
res @rd,imm4 setb addr,imm4 test addr
|
||||
res addr(rd),imm4 setb rbd,imm4 test addr(rd)
|
||||
res addr,imm4 setb rbd,rs test rd
|
||||
res rd,imm4 setflg imm4 testb @rd
|
||||
res rd,rs sinb rbd,imm16 testb addr
|
||||
resb @rd,imm4 sinb rd,imm16 testb addr(rd)
|
||||
resb addr(rd),imm4 sind @rd,@rs,ra testb rbd
|
||||
resb addr,imm4 sindb @rd,@rs,rba testl @rd
|
||||
resb rbd,imm4 sinib @rd,@rs,ra testl addr
|
||||
resb rbd,rs sinibr @rd,@rs,ra testl addr(rd)
|
||||
resflg imm4 sla rd,imm8 testl rrd
|
||||
ret cc slab rbd,imm8 trdb @rd,@rs,rba
|
||||
rl rd,imm1or2 slal rrd,imm8 trdrb @rd,@rs,rba
|
||||
rlb rbd,imm1or2 sll rd,imm8 trib @rd,@rs,rbr
|
||||
rlc rd,imm1or2 sllb rbd,imm8 trirb @rd,@rs,rbr
|
||||
rlcb rbd,imm1or2 slll rrd,imm8 trtdrb @ra,@rb,rbr
|
||||
rldb rbb,rba sout imm16,rs trtib @ra,@rb,rr
|
||||
rr rd,imm1or2 soutb imm16,rbs trtirb @ra,@rb,rbr
|
||||
rrb rbd,imm1or2 soutd @rd,@rs,ra trtrb @ra,@rb,rbr
|
||||
rrc rd,imm1or2 soutdb @rd,@rs,rba tset @rd
|
||||
rrcb rbd,imm1or2 soutib @rd,@rs,ra tset addr
|
||||
rrdb rbb,rba soutibr @rd,@rs,ra tset addr(rd)
|
||||
rsvd36 sra rd,imm8 tset rd
|
||||
rsvd38 srab rbd,imm8 tsetb @rd
|
||||
rsvd78 sral rrd,imm8 tsetb addr
|
||||
rsvd7e srl rd,imm8 tsetb addr(rd)
|
||||
rsvd9d srlb rbd,imm8 tsetb rbd
|
||||
rsvd9f srll rrd,imm8 xor rd,@rs
|
||||
rsvdb9 sub rd,@rs xor rd,addr
|
||||
rsvdbf sub rd,addr xor rd,addr(rs)
|
||||
sbc rd,rs sub rd,addr(rs) xor rd,imm16
|
||||
sbcb rbd,rbs sub rd,imm16 xor rd,rs
|
||||
sc imm8 sub rd,rs xorb rbd,@rs
|
||||
sda rd,rs subb rbd,@rs xorb rbd,addr
|
||||
sdab rbd,rs subb rbd,addr xorb rbd,addr(rs)
|
||||
sdal rrd,rs subb rbd,addr(rs) xorb rbd,imm8
|
||||
sdl rd,rs subb rbd,imm8 xorb rbd,rbs
|
||||
sdlb rbd,rs subb rbd,rbs xorb rbd,rbs
|
||||
sdll rrd,rs subl rrd,@rs
|
||||
set @rd,imm4 subl rrd,addr
|
||||
set addr(rd),imm4 subl rrd,addr(rs)
|
||||
|
||||
|
||||
File: as.info, Node: Acknowledgements, Next: Index, Prev: Copying, Up: Top
|
||||
|
||||
Acknowledgements
|
||||
****************
|
||||
|
||||
If you've contributed to `as' and your name isn't listed here, it is
|
||||
not meant as a slight. We just don't know about it. Send mail to the
|
||||
maintainer, and we'll correct the situation. Currently (June 1993), the
|
||||
maintainer is Ken Raeburn (email address `raeburn@cygnus.com').
|
||||
|
||||
Dean Elsner wrote the original GNU assembler for the VAX.(1)
|
||||
|
||||
Jay Fenlason maintained GAS for a while, adding support for
|
||||
gdb-specific debug information and the 68k series machines, most of the
|
||||
preprocessing pass, and extensive changes in messages.c, input-file.c,
|
||||
write.c.
|
||||
|
||||
K. Richard Pixley maintained GAS for a while, adding various
|
||||
enhancements and many bug fixes, including merging support for several
|
||||
processors, breaking GAS up to handle multiple object file format
|
||||
backends (including heavy rewrite, testing, an integration of the coff
|
||||
and b.out backends), adding configuration including heavy testing and
|
||||
verification of cross assemblers and file splits and renaming,
|
||||
converted GAS to strictly ansi C including full prototypes, added
|
||||
support for m680[34]0 & cpu32, considerable work on i960 including a
|
||||
COFF port (including considerable amounts of reverse engineering), a
|
||||
SPARC opcode file rewrite, DECstation, rs6000, and hp300hpux host
|
||||
ports, updated "know" assertions and made them work, much other
|
||||
reorganization, cleanup, and lint.
|
||||
|
||||
Ken Raeburn wrote the high-level BFD interface code to replace most
|
||||
of the code in format-specific I/O modules.
|
||||
|
||||
The original VMS support was contributed by David L. Kashtan. Eric
|
||||
Youngdale has done much work with it since.
|
||||
|
||||
The Intel 80386 machine description was written by Eliot Dresselhaus.
|
||||
|
||||
Minh Tran-Le at IntelliCorp contributed some AIX 386 support.
|
||||
|
||||
The Motorola 88k machine description was contributed by Devon Bowen
|
||||
of Buffalo University and Torbjorn Granlund of the Swedish Institute of
|
||||
Computer Science.
|
||||
|
||||
Keith Knowles at the Open Software Foundation wrote the original
|
||||
MIPS back end (tc-mips.c, tc-mips.h), and contributed Rose format
|
||||
support (which hasn't been merged in yet). Ralph Campbell worked with
|
||||
the MIPS code to support a.out format.
|
||||
|
||||
Support for the Zilog Z8k and Hitachi H8/300 and H8/500 processors
|
||||
(tc-z8k, tc-h8300, tc-h8500), and IEEE 695 object file format
|
||||
(obj-ieee), was written by Steve Chamberlain of Cygnus Support. Steve
|
||||
also modified the COFF back end to use BFD for some low-level
|
||||
operations, for use with the H8/300 and AMD 29k targets.
|
||||
|
||||
John Gilmore built the AMD 29000 support, added .include support, and
|
||||
simplified the configuration of which versions accept which pseudo-ops.
|
||||
He updated the 68k machine description so that Motorola's opcodes
|
||||
always produced fixed-size instructions (e.g. jsr), while synthetic
|
||||
instructions remained shrinkable (jbsr). John fixed many bugs,
|
||||
including true tested cross-compilation support, and one bug in
|
||||
relaxation that took a week and required the apocryphal one-bit fix.
|
||||
|
||||
Ian Lance Taylor of Cygnus Support merged the Motorola and MIT
|
||||
syntaxes for the 68k, completed support for some COFF targets (68k,
|
||||
i386 SVR3, and SCO Unix), and made a few other minor patches.
|
||||
|
||||
Steve Chamberlain made `as' able to generate listings.
|
||||
|
||||
Support for the HP9000/300 was contributed by Hewlett-Packard.
|
||||
|
||||
Support for ELF format files has been worked on by Mark Eichin of
|
||||
Cygnus Support (original, incomplete implementation for SPARC), Pete
|
||||
Hoogenboom and Jeff Law at the University of Utah (HPPA mainly),
|
||||
Michael Meissner of the Open Software Foundation (i386 mainly), and Ken
|
||||
Raeburn of Cygnus Support (sparc, and some initial 64-bit support).
|
||||
|
||||
Several engineers at Cygnus Support have also provided many small
|
||||
bug fixes and configuration enhancements.
|
||||
|
||||
Many others have contributed large or small bugfixes and
|
||||
enhancements. If you've contributed significant work and are not
|
||||
mentioned on this list, and want to be, let us know. Some of the
|
||||
history has been lost; we aren't intentionally leaving anyone out.
|
||||
|
||||
---------- Footnotes ----------
|
||||
|
||||
(1) Any more details?
|
||||
|
394
gas/doc/as.info-5
Normal file
394
gas/doc/as.info-5
Normal file
|
@ -0,0 +1,394 @@
|
|||
This is Info file as.info, produced by Makeinfo-1.55 from the input
|
||||
file ./as.texinfo.
|
||||
|
||||
START-INFO-DIR-ENTRY
|
||||
* As:: The GNU assembler.
|
||||
END-INFO-DIR-ENTRY
|
||||
|
||||
This file documents the GNU Assembler "as".
|
||||
|
||||
Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of this
|
||||
manual provided the copyright notice and this permission notice are
|
||||
preserved on all copies.
|
||||
|
||||
Permission is granted to copy and distribute modified versions of
|
||||
this manual under the conditions for verbatim copying, provided also
|
||||
that the section entitled "GNU General Public License" is included
|
||||
exactly as in the original, and provided that the entire resulting
|
||||
derived work is distributed under the terms of a permission notice
|
||||
identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this
|
||||
manual into another language, under the above conditions for modified
|
||||
versions, except that the section entitled "GNU General Public License"
|
||||
may be included in a translation approved by the Free Software
|
||||
Foundation instead of in the original English.
|
||||
|
||||
|
||||
File: as.info, Node: Copying, Next: Acknowledgements, Prev: Machine Dependencies, Up: Top
|
||||
|
||||
|
||||
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
**************************
|
||||
|
||||
Version 2, June 1991
|
||||
|
||||
Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675
|
||||
Mass Ave, Cambridge, MA 02139, USA
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Preamble
|
||||
========
|
||||
|
||||
The licenses for most software are designed to take away your
|
||||
freedom to share and change it. By contrast, the GNU General Public
|
||||
License is intended to guarantee your freedom to share and change free
|
||||
software--to make sure the software is free for all its users. This
|
||||
General Public License applies to most of the Free Software
|
||||
Foundation's software and to any other program whose authors commit to
|
||||
using it. (Some other Free Software Foundation software is covered by
|
||||
the GNU Library General Public License instead.) You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
this service if you wish), that you receive source code or can get it
|
||||
if you want it, that you can change the software or use pieces of it in
|
||||
new free programs; and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to make restrictions that forbid
|
||||
anyone to deny you these rights or to ask you to surrender the rights.
|
||||
These restrictions translate to certain responsibilities for you if you
|
||||
distribute copies of the software, or if you modify it.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must give the recipients all the rights that
|
||||
you have. You must make sure that they, too, receive or can get the
|
||||
source code. And you must show them these terms so they know their
|
||||
rights.
|
||||
|
||||
We protect your rights with two steps: (1) copyright the software,
|
||||
and (2) offer you this license which gives you legal permission to copy,
|
||||
distribute and/or modify the software.
|
||||
|
||||
Also, for each author's protection and ours, we want to make certain
|
||||
that everyone understands that there is no warranty for this free
|
||||
software. If the software is modified by someone else and passed on, we
|
||||
want its recipients to know that what they have is not the original, so
|
||||
that any problems introduced by others will not reflect on the original
|
||||
authors' reputations.
|
||||
|
||||
Finally, any free program is threatened constantly by software
|
||||
patents. We wish to avoid the danger that redistributors of a free
|
||||
program will individually obtain patent licenses, in effect making the
|
||||
program proprietary. To prevent this, we have made it clear that any
|
||||
patent must be licensed for everyone's free use or not licensed at all.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
1. This License applies to any program or other work which contains a
|
||||
notice placed by the copyright holder saying it may be distributed
|
||||
under the terms of this General Public License. The "Program",
|
||||
below, refers to any such program or work, and a "work based on
|
||||
the Program" means either the Program or any derivative work under
|
||||
copyright law: that is to say, a work containing the Program or a
|
||||
portion of it, either verbatim or with modifications and/or
|
||||
translated into another language. (Hereinafter, translation is
|
||||
included without limitation in the term "modification".) Each
|
||||
licensee is addressed as "you".
|
||||
|
||||
Activities other than copying, distribution and modification are
|
||||
not covered by this License; they are outside its scope. The act
|
||||
of running the Program is not restricted, and the output from the
|
||||
Program is covered only if its contents constitute a work based on
|
||||
the Program (independent of having been made by running the
|
||||
Program). Whether that is true depends on what the Program does.
|
||||
|
||||
2. You may copy and distribute verbatim copies of the Program's
|
||||
source code as you receive it, in any medium, provided that you
|
||||
conspicuously and appropriately publish on each copy an appropriate
|
||||
copyright notice and disclaimer of warranty; keep intact all the
|
||||
notices that refer to this License and to the absence of any
|
||||
warranty; and give any other recipients of the Program a copy of
|
||||
this License along with the Program.
|
||||
|
||||
You may charge a fee for the physical act of transferring a copy,
|
||||
and you may at your option offer warranty protection in exchange
|
||||
for a fee.
|
||||
|
||||
3. You may modify your copy or copies of the Program or any portion
|
||||
of it, thus forming a work based on the Program, and copy and
|
||||
distribute such modifications or work under the terms of Section 1
|
||||
above, provided that you also meet all of these conditions:
|
||||
|
||||
a. You must cause the modified files to carry prominent notices
|
||||
stating that you changed the files and the date of any change.
|
||||
|
||||
b. You must cause any work that you distribute or publish, that
|
||||
in whole or in part contains or is derived from the Program
|
||||
or any part thereof, to be licensed as a whole at no charge
|
||||
to all third parties under the terms of this License.
|
||||
|
||||
c. If the modified program normally reads commands interactively
|
||||
when run, you must cause it, when started running for such
|
||||
interactive use in the most ordinary way, to print or display
|
||||
an announcement including an appropriate copyright notice and
|
||||
a notice that there is no warranty (or else, saying that you
|
||||
provide a warranty) and that users may redistribute the
|
||||
program under these conditions, and telling the user how to
|
||||
view a copy of this License. (Exception: if the Program
|
||||
itself is interactive but does not normally print such an
|
||||
announcement, your work based on the Program is not required
|
||||
to print an announcement.)
|
||||
|
||||
These requirements apply to the modified work as a whole. If
|
||||
identifiable sections of that work are not derived from the
|
||||
Program, and can be reasonably considered independent and separate
|
||||
works in themselves, then this License, and its terms, do not
|
||||
apply to those sections when you distribute them as separate
|
||||
works. But when you distribute the same sections as part of a
|
||||
whole which is a work based on the Program, the distribution of
|
||||
the whole must be on the terms of this License, whose permissions
|
||||
for other licensees extend to the entire whole, and thus to each
|
||||
and every part regardless of who wrote it.
|
||||
|
||||
Thus, it is not the intent of this section to claim rights or
|
||||
contest your rights to work written entirely by you; rather, the
|
||||
intent is to exercise the right to control the distribution of
|
||||
derivative or collective works based on the Program.
|
||||
|
||||
In addition, mere aggregation of another work not based on the
|
||||
Program with the Program (or with a work based on the Program) on
|
||||
a volume of a storage or distribution medium does not bring the
|
||||
other work under the scope of this License.
|
||||
|
||||
4. You may copy and distribute the Program (or a work based on it,
|
||||
under Section 2) in object code or executable form under the terms
|
||||
of Sections 1 and 2 above provided that you also do one of the
|
||||
following:
|
||||
|
||||
a. Accompany it with the complete corresponding machine-readable
|
||||
source code, which must be distributed under the terms of
|
||||
Sections 1 and 2 above on a medium customarily used for
|
||||
software interchange; or,
|
||||
|
||||
b. Accompany it with a written offer, valid for at least three
|
||||
years, to give any third party, for a charge no more than your
|
||||
cost of physically performing source distribution, a complete
|
||||
machine-readable copy of the corresponding source code, to be
|
||||
distributed under the terms of Sections 1 and 2 above on a
|
||||
medium customarily used for software interchange; or,
|
||||
|
||||
c. Accompany it with the information you received as to the offer
|
||||
to distribute corresponding source code. (This alternative is
|
||||
allowed only for noncommercial distribution and only if you
|
||||
received the program in object code or executable form with
|
||||
such an offer, in accord with Subsection b above.)
|
||||
|
||||
The source code for a work means the preferred form of the work for
|
||||
making modifications to it. For an executable work, complete
|
||||
source code means all the source code for all modules it contains,
|
||||
plus any associated interface definition files, plus the scripts
|
||||
used to control compilation and installation of the executable.
|
||||
However, as a special exception, the source code distributed need
|
||||
not include anything that is normally distributed (in either
|
||||
source or binary form) with the major components (compiler,
|
||||
kernel, and so on) of the operating system on which the executable
|
||||
runs, unless that component itself accompanies the executable.
|
||||
|
||||
If distribution of executable or object code is made by offering
|
||||
access to copy from a designated place, then offering equivalent
|
||||
access to copy the source code from the same place counts as
|
||||
distribution of the source code, even though third parties are not
|
||||
compelled to copy the source along with the object code.
|
||||
|
||||
5. You may not copy, modify, sublicense, or distribute the Program
|
||||
except as expressly provided under this License. Any attempt
|
||||
otherwise to copy, modify, sublicense or distribute the Program is
|
||||
void, and will automatically terminate your rights under this
|
||||
License. However, parties who have received copies, or rights,
|
||||
from you under this License will not have their licenses
|
||||
terminated so long as such parties remain in full compliance.
|
||||
|
||||
6. You are not required to accept this License, since you have not
|
||||
signed it. However, nothing else grants you permission to modify
|
||||
or distribute the Program or its derivative works. These actions
|
||||
are prohibited by law if you do not accept this License.
|
||||
Therefore, by modifying or distributing the Program (or any work
|
||||
based on the Program), you indicate your acceptance of this
|
||||
License to do so, and all its terms and conditions for copying,
|
||||
distributing or modifying the Program or works based on it.
|
||||
|
||||
7. Each time you redistribute the Program (or any work based on the
|
||||
Program), the recipient automatically receives a license from the
|
||||
original licensor to copy, distribute or modify the Program
|
||||
subject to these terms and conditions. You may not impose any
|
||||
further restrictions on the recipients' exercise of the rights
|
||||
granted herein. You are not responsible for enforcing compliance
|
||||
by third parties to this License.
|
||||
|
||||
8. If, as a consequence of a court judgment or allegation of patent
|
||||
infringement or for any other reason (not limited to patent
|
||||
issues), conditions are imposed on you (whether by court order,
|
||||
agreement or otherwise) that contradict the conditions of this
|
||||
License, they do not excuse you from the conditions of this
|
||||
License. If you cannot distribute so as to satisfy simultaneously
|
||||
your obligations under this License and any other pertinent
|
||||
obligations, then as a consequence you may not distribute the
|
||||
Program at all. For example, if a patent license would not permit
|
||||
royalty-free redistribution of the Program by all those who
|
||||
receive copies directly or indirectly through you, then the only
|
||||
way you could satisfy both it and this License would be to refrain
|
||||
entirely from distribution of the Program.
|
||||
|
||||
If any portion of this section is held invalid or unenforceable
|
||||
under any particular circumstance, the balance of the section is
|
||||
intended to apply and the section as a whole is intended to apply
|
||||
in other circumstances.
|
||||
|
||||
It is not the purpose of this section to induce you to infringe any
|
||||
patents or other property right claims or to contest validity of
|
||||
any such claims; this section has the sole purpose of protecting
|
||||
the integrity of the free software distribution system, which is
|
||||
implemented by public license practices. Many people have made
|
||||
generous contributions to the wide range of software distributed
|
||||
through that system in reliance on consistent application of that
|
||||
system; it is up to the author/donor to decide if he or she is
|
||||
willing to distribute software through any other system and a
|
||||
licensee cannot impose that choice.
|
||||
|
||||
This section is intended to make thoroughly clear what is believed
|
||||
to be a consequence of the rest of this License.
|
||||
|
||||
9. If the distribution and/or use of the Program is restricted in
|
||||
certain countries either by patents or by copyrighted interfaces,
|
||||
the original copyright holder who places the Program under this
|
||||
License may add an explicit geographical distribution limitation
|
||||
excluding those countries, so that distribution is permitted only
|
||||
in or among countries not thus excluded. In such case, this
|
||||
License incorporates the limitation as if written in the body of
|
||||
this License.
|
||||
|
||||
10. The Free Software Foundation may publish revised and/or new
|
||||
versions of the General Public License from time to time. Such
|
||||
new versions will be similar in spirit to the present version, but
|
||||
may differ in detail to address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the
|
||||
Program specifies a version number of this License which applies
|
||||
to it and "any later version", you have the option of following
|
||||
the terms and conditions either of that version or of any later
|
||||
version published by the Free Software Foundation. If the Program
|
||||
does not specify a version number of this License, you may choose
|
||||
any version ever published by the Free Software Foundation.
|
||||
|
||||
11. If you wish to incorporate parts of the Program into other free
|
||||
programs whose distribution conditions are different, write to the
|
||||
author to ask for permission. For software which is copyrighted
|
||||
by the Free Software Foundation, write to the Free Software
|
||||
Foundation; we sometimes make exceptions for this. Our decision
|
||||
will be guided by the two goals of preserving the free status of
|
||||
all derivatives of our free software and of promoting the sharing
|
||||
and reuse of software generally.
|
||||
|
||||
NO WARRANTY
|
||||
|
||||
12. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
|
||||
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
|
||||
LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
|
||||
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
|
||||
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
|
||||
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
|
||||
FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
|
||||
QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
|
||||
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
|
||||
SERVICING, REPAIR OR CORRECTION.
|
||||
|
||||
13. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
|
||||
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
|
||||
MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
|
||||
LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
|
||||
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
|
||||
INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
|
||||
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
|
||||
OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
|
||||
OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
|
||||
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
How to Apply These Terms to Your New Programs
|
||||
=============================================
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
possible use to the public, the best way to achieve this is to make it
|
||||
free software which everyone can redistribute and change under these
|
||||
terms.
|
||||
|
||||
To do so, attach the following notices to the program. It is safest
|
||||
to attach them to the start of each source file to most effectively
|
||||
convey the exclusion of warranty; and each file should have at least
|
||||
the "copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
ONE LINE TO GIVE THE PROGRAM'S NAME AND AN IDEA OF WHAT IT DOES.
|
||||
Copyright (C) 19YY NAME OF AUTHOR
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
|
||||
Also add information on how to contact you by electronic and paper
|
||||
mail.
|
||||
|
||||
If the program is interactive, make it output a short notice like
|
||||
this when it starts in an interactive mode:
|
||||
|
||||
Gnomovision version 69, Copyright (C) 19YY NAME OF AUTHOR
|
||||
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
|
||||
type `show w'. This is free software, and you are welcome
|
||||
to redistribute it under certain conditions; type `show c'
|
||||
for details.
|
||||
|
||||
The hypothetical commands `show w' and `show c' should show the
|
||||
appropriate parts of the General Public License. Of course, the
|
||||
commands you use may be called something other than `show w' and `show
|
||||
c'; they could even be mouse-clicks or menu items--whatever suits your
|
||||
program.
|
||||
|
||||
You should also get your employer (if you work as a programmer) or
|
||||
your school, if any, to sign a "copyright disclaimer" for the program,
|
||||
if necessary. Here is a sample; alter the names:
|
||||
|
||||
Yoyodyne, Inc., hereby disclaims all copyright
|
||||
interest in the program `Gnomovision'
|
||||
(which makes passes at compilers) written
|
||||
by James Hacker.
|
||||
|
||||
SIGNATURE OF TY COON, 1 April 1989
|
||||
Ty Coon, President of Vice
|
||||
|
||||
This General Public License does not permit incorporating your
|
||||
program into proprietary programs. If your program is a subroutine
|
||||
library, you may consider it more useful to permit linking proprietary
|
||||
applications with the library. If this is what you want to do, use the
|
||||
GNU Library General Public License instead of this License.
|
||||
|
65
ld/ld.info
Normal file
65
ld/ld.info
Normal file
|
@ -0,0 +1,65 @@
|
|||
This is Info file ld.info, produced by Makeinfo-1.55 from the input
|
||||
file ./ld.texinfo.
|
||||
|
||||
START-INFO-DIR-ENTRY
|
||||
* Ld:: The GNU linker.
|
||||
END-INFO-DIR-ENTRY
|
||||
|
||||
This file documents the GNU linker LD.
|
||||
|
||||
Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of this
|
||||
manual provided the copyright notice and this permission notice are
|
||||
preserved on all copies.
|
||||
|
||||
Permission is granted to copy and distribute modified versions of
|
||||
this manual under the conditions for verbatim copying, provided also
|
||||
that the entire resulting derived work is distributed under the terms
|
||||
of a permission notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this
|
||||
manual into another language, under the above conditions for modified
|
||||
versions.
|
||||
|
||||
|
||||
Indirect:
|
||||
ld.info-1: 857
|
||||
ld.info-2: 49400
|
||||
|
||||
Tag Table:
|
||||
(Indirect)
|
||||
Node: Top857
|
||||
Node: Overview1330
|
||||
Node: Invocation2478
|
||||
Node: Options2886
|
||||
Node: Environment20209
|
||||
Node: Commands21154
|
||||
Node: Scripts22148
|
||||
Node: Expressions23246
|
||||
Node: Integers24173
|
||||
Node: Symbols25012
|
||||
Node: Location Counter25572
|
||||
Node: Operators26768
|
||||
Node: Evaluation27678
|
||||
Node: Assignment28373
|
||||
Node: Arithmetic Functions31454
|
||||
Node: MEMORY35234
|
||||
Node: SECTIONS37821
|
||||
Node: Section Definition39419
|
||||
Node: Section Placement40867
|
||||
Node: Section Data Expressions45560
|
||||
Node: Section Options49400
|
||||
Node: Entry Point51581
|
||||
Node: Option Commands53174
|
||||
Node: Machine Dependent56493
|
||||
Node: H8/30056913
|
||||
Node: i96057708
|
||||
Node: BFD58918
|
||||
Node: BFD outline62281
|
||||
Node: BFD information loss63566
|
||||
Node: Canonical format66074
|
||||
Node: MRI70420
|
||||
Node: Index74894
|
||||
|
||||
End Tag Table
|
1255
ld/ld.info-1
Normal file
1255
ld/ld.info-1
Normal file
File diff suppressed because it is too large
Load diff
941
ld/ld.info-2
Normal file
941
ld/ld.info-2
Normal file
|
@ -0,0 +1,941 @@
|
|||
This is Info file ld.info, produced by Makeinfo-1.55 from the input
|
||||
file ./ld.texinfo.
|
||||
|
||||
START-INFO-DIR-ENTRY
|
||||
* Ld:: The GNU linker.
|
||||
END-INFO-DIR-ENTRY
|
||||
|
||||
This file documents the GNU linker LD.
|
||||
|
||||
Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of this
|
||||
manual provided the copyright notice and this permission notice are
|
||||
preserved on all copies.
|
||||
|
||||
Permission is granted to copy and distribute modified versions of
|
||||
this manual under the conditions for verbatim copying, provided also
|
||||
that the entire resulting derived work is distributed under the terms
|
||||
of a permission notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this
|
||||
manual into another language, under the above conditions for modified
|
||||
versions.
|
||||
|
||||
|
||||
File: ld.info, Node: Section Options, Prev: Section Data Expressions, Up: SECTIONS
|
||||
|
||||
Optional Section Attributes
|
||||
---------------------------
|
||||
|
||||
Here is the full syntax of a section definition, including all the
|
||||
optional portions:
|
||||
|
||||
SECTIONS {
|
||||
...
|
||||
SECNAME START BLOCK(ALIGN) (NOLOAD) : { CONTENTS } =FILL >REGION
|
||||
...
|
||||
}
|
||||
|
||||
SECNAME and CONTENTS are required. *Note Section Definition::, and
|
||||
*note Section Placement::. for details on CONTENTS. The remaining
|
||||
elements--START, `BLOCK(ALIGN)', `(NOLOAD)' `=FILL', and `>REGION'--are
|
||||
all optional.
|
||||
|
||||
`START'
|
||||
You can force the output section to be loaded at a specified
|
||||
address by specifying START immediately following the section name.
|
||||
sTART can be represented as any expression. The following example
|
||||
generates section OUTPUT at location `0x40000000':
|
||||
SECTIONS {
|
||||
...
|
||||
output 0x40000000: {
|
||||
...
|
||||
}
|
||||
...
|
||||
}
|
||||
|
||||
`BLOCK(ALIGN)'
|
||||
You can include `BLOCK()' specification to advance the location
|
||||
counter `.' prior to the beginning of the section, so that the
|
||||
section will begin at the specified alignment. ALIGN is an
|
||||
expression.
|
||||
|
||||
`(NOLOAD)'
|
||||
Use `(NOLOAD)' to prevent a section from being loaded into memory
|
||||
each time it is accessed. For example, in the script sample
|
||||
below, the `ROM' segment is addressed at memory location `0' and
|
||||
does not need to be loaded into each object file:
|
||||
SECTIONS {
|
||||
ROM 0 (NOLOAD) : { ... }
|
||||
...
|
||||
}
|
||||
|
||||
`=FILL'
|
||||
Including `=FILL' in a section definition specifies the initial
|
||||
fill value for that section. You may use any expression to
|
||||
specify FILL. Any unallocated holes in the current output section
|
||||
when written to the output file will be filled with the two least
|
||||
significant bytes of the value, repeated as necessary. You can
|
||||
also change the fill value with a `FILL' statement in the CONTENTS
|
||||
of a section definition.
|
||||
|
||||
`>REGION'
|
||||
Assign this section to a previously defined region of memory.
|
||||
*Note MEMORY::.
|
||||
|
||||
|
||||
File: ld.info, Node: Entry Point, Next: Option Commands, Prev: SECTIONS, Up: Commands
|
||||
|
||||
The Entry Point
|
||||
===============
|
||||
|
||||
The linker command language includes a command specifically for
|
||||
defining the first executable instruction in an output file (its "entry
|
||||
point"). Its argument is a symbol name:
|
||||
ENTRY(SYMBOL)
|
||||
|
||||
Like symbol assignments, the `ENTRY' command may be placed either as
|
||||
an independent command in the command file, or among the section
|
||||
definitions within the `SECTIONS' command--whatever makes the most
|
||||
sense for your layout.
|
||||
|
||||
`ENTRY' is only one of several ways of choosing the entry point.
|
||||
You may indicate it in any of the following ways (shown in descending
|
||||
order of priority: methods higher in the list override methods lower
|
||||
down).
|
||||
* the `-e' ENTRY command-line option;
|
||||
|
||||
* the `ENTRY(SYMBOL' command in a linker control script;
|
||||
|
||||
* the value of the symbol `start', if present;
|
||||
|
||||
* the value of the symbol `_main', if present;
|
||||
|
||||
* the address of the first byte of the `.text' section, if present;
|
||||
|
||||
* The address `0'.
|
||||
|
||||
For example, you can use these rules to generate an entry point with
|
||||
an assignment statement: if no symbol `start' is defined within your
|
||||
input files, you can simply define it, assigning it an appropriate
|
||||
value--
|
||||
start = 0x2020;
|
||||
|
||||
The example shows an absolute address, but you can use any expression.
|
||||
For example, if your input object files use some other symbol-name
|
||||
convention for the entry point, you can just assign the value of
|
||||
whatever symbol contains the start address to `start':
|
||||
start = other_symbol ;
|
||||
|
||||
|
||||
File: ld.info, Node: Option Commands, Prev: Entry Point, Up: Commands
|
||||
|
||||
Option Commands
|
||||
===============
|
||||
|
||||
The command language includes a number of other commands that you can
|
||||
use for specialized purposes. They are similar in purpose to
|
||||
command-line options.
|
||||
|
||||
`FLOAT'
|
||||
`NOFLOAT'
|
||||
These keywords were used in some older linkers to request a
|
||||
particular math subroutine library. `ld' doesn't use the
|
||||
keywords, assuming instead that any necessary subroutines are in
|
||||
libraries specified using the general mechanisms for linking to
|
||||
archives; but to permit the use of scripts that were written for
|
||||
the older linkers, the keywords `FLOAT' and `NOFLOAT' are accepted
|
||||
and ignored.
|
||||
|
||||
`FORCE_COMMON_ALLOCATION'
|
||||
This command has the same effect as the `-d' command-line option:
|
||||
to make `ld' assign space to common symbols even if a relocatable
|
||||
output file is specified (`-r').
|
||||
|
||||
`INPUT ( FILE, FILE, ... )'
|
||||
`INPUT ( FILE FILE ... )'
|
||||
Use this command to include binary input files in the link, without
|
||||
including them in a particular section definition. Specify the
|
||||
full name for each FILE, including `.a' if required.
|
||||
|
||||
`ld' searches for each FILE through the archive-library search
|
||||
path, just as for files you specify on the command line. See the
|
||||
description of `-L' in *Note Command Line Options: Options.
|
||||
|
||||
`OUTPUT ( FILENAME )'
|
||||
Use this command to name the link output file FILENAME. The
|
||||
effect of `OUTPUT(FILENAME)' is identical to the effect of
|
||||
`-o FILENAME', which overrides it. You can use this command to
|
||||
supply a default output-file name other than `a.out'.
|
||||
|
||||
`OUTPUT_ARCH ( BFDNAME )'
|
||||
Specify a particular output machine architecture, with one of the
|
||||
names used by the BFD back-end routines (*note BFD::.). This
|
||||
command is often unnecessary; the architecture is most often set
|
||||
implicitly by either the system BFD configuration or as a side
|
||||
effect of the `OUTPUT_FORMAT' command.
|
||||
|
||||
`OUTPUT_FORMAT ( BFDNAME )'
|
||||
Specify a particular output format, with one of the names used by
|
||||
the BFD back-end routines (*note BFD::.). The effect is identical
|
||||
to the effect of the `-oformat' command-line option. This
|
||||
selection will only affect the output file; the related command
|
||||
`TARGET' affects primarily input files.
|
||||
|
||||
`SEARCH_DIR ( PATH )'
|
||||
Add PATH to the list of paths where `ld' looks for archive
|
||||
libraries. `SEARCH_DIR(PATH)' has the same effect as `-LPATH' on
|
||||
the command line.
|
||||
|
||||
`STARTUP ( FILENAME )'
|
||||
Ensure that FILENAME is the first input file used in the link
|
||||
process.
|
||||
|
||||
`TARGET ( FORMAT )'
|
||||
Change the input-file object code format (like the command-line
|
||||
option `-b' or its synonym `-format'). The argument FORMAT is one
|
||||
of the strings used by BFD to name binary formats. If `TARGET' is
|
||||
specified but `OUTPUT_FORMAT' is not, the last `TARGET' argument
|
||||
is also used as the default format for the `ld' output file.
|
||||
*Note BFD::.
|
||||
|
||||
If you don't use the `TARGET' command, `ld' uses the value of the
|
||||
environment variable `GNUTARGET', if available, to select the
|
||||
output file format. If that variable is also absent, `ld' uses
|
||||
the default format configured for your machine in the BFD
|
||||
libraries.
|
||||
|
||||
|
||||
File: ld.info, Node: Machine Dependent, Next: BFD, Prev: Commands, Up: Top
|
||||
|
||||
Machine Dependent Features
|
||||
**************************
|
||||
|
||||
`ld' has additional features on some platforms; the following
|
||||
sections describe them. Machines where `ld' has no additional
|
||||
functionality are not listed.
|
||||
|
||||
* Menu:
|
||||
|
||||
* H8/300:: `ld' and the H8/300
|
||||
* i960:: `ld' and the Intel 960 family
|
||||
|
||||
|
||||
File: ld.info, Node: H8/300, Next: i960, Up: Machine Dependent
|
||||
|
||||
`ld' and the H8/300
|
||||
===================
|
||||
|
||||
For the H8/300, `ld' can perform these global optimizations when you
|
||||
specify the `-relax' command-line option.
|
||||
|
||||
*relaxing address modes*
|
||||
`ld' finds all `jsr' and `jmp' instructions whose targets are
|
||||
within eight bits, and turns them into eight-bit program-counter
|
||||
relative `bsr' and `bra' instructions, respectively.
|
||||
|
||||
*synthesizing instructions*
|
||||
`ld' finds all `mov.b' instructions which use the sixteen-bit
|
||||
absolute address form, but refer to the top page of memory, and
|
||||
changes them to use the eight-bit address form. (That is: the
|
||||
linker turns `mov.b `@'AA:16' into `mov.b `@'AA:8' whenever the
|
||||
address AA is in the top page of memory).
|
||||
|
||||
|
||||
File: ld.info, Node: i960, Prev: H8/300, Up: Machine Dependent
|
||||
|
||||
`ld' and the Intel 960 family
|
||||
=============================
|
||||
|
||||
You can use the `-AARCHITECTURE' command line option to specify one
|
||||
of the two-letter names identifying members of the 960 family; the
|
||||
option specifies the desired output target, and warns of any
|
||||
incompatible instructions in the input files. It also modifies the
|
||||
linker's search strategy for archive libraries, to support the use of
|
||||
libraries specific to each particular architecture, by including in the
|
||||
search loop names suffixed with the string identifying the architecture.
|
||||
|
||||
For example, if your `ld' command line included `-ACA' as well as
|
||||
`-ltry', the linker would look (in its built-in search paths, and in
|
||||
any paths you specify with `-L') for a library with the names
|
||||
|
||||
try
|
||||
libtry.a
|
||||
tryca
|
||||
libtryca.a
|
||||
|
||||
The first two possibilities would be considered in any event; the last
|
||||
two are due to the use of `-ACA'.
|
||||
|
||||
You can meaningfully use `-A' more than once on a command line, since
|
||||
the 960 architecture family allows combination of target architectures;
|
||||
each use will add another pair of name variants to search for when `-l'
|
||||
specifies a library.
|
||||
|
||||
|
||||
File: ld.info, Node: BFD, Next: MRI, Prev: Machine Dependent, Up: Top
|
||||
|
||||
BFD
|
||||
***
|
||||
|
||||
The linker accesses object and archive files using the BFD libraries.
|
||||
These libraries allow the linker to use the same routines to operate on
|
||||
object files whatever the object file format. A different object file
|
||||
format can be supported simply by creating a new BFD back end and adding
|
||||
it to the library. You can use `objdump -i' (*note objdump:
|
||||
(binutils.info)objdump.) to list all the formats available for each
|
||||
architecture under BFD. This was the list of formats, and of
|
||||
architectures supported for each format, as of the time this manual was
|
||||
prepared:
|
||||
BFD header file version 0.18
|
||||
a.out-i386
|
||||
(header big endian, data big endian)
|
||||
m68k:68020
|
||||
a29k
|
||||
sparc
|
||||
i386
|
||||
a.out-sunos-big
|
||||
(header big endian, data big endian)
|
||||
m68k:68020
|
||||
a29k
|
||||
sparc
|
||||
i386
|
||||
b.out.big
|
||||
(header big endian, data little endian)
|
||||
i960:core
|
||||
b.out.little
|
||||
(header little endian, data little endian)
|
||||
i960:core
|
||||
coff-a29k-big
|
||||
(header big endian, data big endian)
|
||||
a29k
|
||||
coff-h8300
|
||||
(header big endian, data big endian)
|
||||
H8/300
|
||||
coff-i386
|
||||
(header little endian, data little endian)
|
||||
i386
|
||||
coff-Intel-big
|
||||
(header big endian, data little endian)
|
||||
i960:core
|
||||
coff-Intel-little
|
||||
(header little endian, data little endian)
|
||||
i960:core
|
||||
coff-m68k
|
||||
(header big endian, data big endian)
|
||||
m68k:68020
|
||||
coff-m88kbcs
|
||||
(header big endian, data big endian)
|
||||
m88k:88100
|
||||
ecoff-bigmips
|
||||
(header big endian, data big endian)
|
||||
mips
|
||||
ecoff-littlemips
|
||||
(header little endian, data little endian)
|
||||
mips
|
||||
elf-big
|
||||
(header big endian, data big endian)
|
||||
m68k:68020
|
||||
vax
|
||||
i960:core
|
||||
a29k
|
||||
sparc
|
||||
mips
|
||||
i386
|
||||
m88k:88100
|
||||
H8/300
|
||||
rs6000:6000
|
||||
elf-little
|
||||
(header little endian, data little endian)
|
||||
m68k:68020
|
||||
vax
|
||||
i960:core
|
||||
a29k
|
||||
sparc
|
||||
mips
|
||||
i386
|
||||
m88k:88100
|
||||
H8/300
|
||||
rs6000:6000
|
||||
ieee
|
||||
(header big endian, data big endian)
|
||||
m68k:68020
|
||||
vax
|
||||
i960:core
|
||||
a29k
|
||||
sparc
|
||||
mips
|
||||
i386
|
||||
m88k:88100
|
||||
H8/300
|
||||
rs6000:6000
|
||||
srec
|
||||
(header big endian, data big endian)
|
||||
m68k:68020
|
||||
vax
|
||||
i960:core
|
||||
a29k
|
||||
sparc
|
||||
mips
|
||||
i386
|
||||
m88k:88100
|
||||
H8/300
|
||||
rs6000:6000
|
||||
|
||||
As with most implementations, BFD is a compromise between several
|
||||
conflicting requirements. The major factor influencing BFD design was
|
||||
efficiency: any time used converting between formats is time which
|
||||
would not have been spent had BFD not been involved. This is partly
|
||||
offset by abstraction payback; since BFD simplifies applications and
|
||||
back ends, more time and care may be spent optimizing algorithms for a
|
||||
greater speed.
|
||||
|
||||
One minor artifact of the BFD solution which you should bear in mind
|
||||
is the potential for information loss. There are two places where
|
||||
useful information can be lost using the BFD mechanism: during
|
||||
conversion and during output. *Note BFD information loss::.
|
||||
|
||||
* Menu:
|
||||
|
||||
* BFD outline:: How it works: an outline of BFD
|
||||
|
||||
|
||||
File: ld.info, Node: BFD outline, Up: BFD
|
||||
|
||||
How it works: an outline of BFD
|
||||
===============================
|
||||
|
||||
When an object file is opened, BFD subroutines automatically
|
||||
determine the format of the input object file. They then build a
|
||||
descriptor in memory with pointers to routines that will be used to
|
||||
access elements of the object file's data structures.
|
||||
|
||||
As different information from the the object files is required, BFD
|
||||
reads from different sections of the file and processes them. For
|
||||
example, a very common operation for the linker is processing symbol
|
||||
tables. Each BFD back end provides a routine for converting between
|
||||
the object file's representation of symbols and an internal canonical
|
||||
format. When the linker asks for the symbol table of an object file, it
|
||||
calls through a memory pointer to the routine from the relevant BFD
|
||||
back end which reads and converts the table into a canonical form. The
|
||||
linker then operates upon the canonical form. When the link is finished
|
||||
and the linker writes the output file's symbol table, another BFD back
|
||||
end routine is called to take the newly created symbol table and
|
||||
convert it into the chosen output format.
|
||||
|
||||
* Menu:
|
||||
|
||||
* BFD information loss:: Information Loss
|
||||
* Canonical format:: The BFD canonical object-file format
|
||||
|
||||
|
||||
File: ld.info, Node: BFD information loss, Next: Canonical format, Up: BFD outline
|
||||
|
||||
Information Loss
|
||||
----------------
|
||||
|
||||
*Information can be lost during output.* The output formats
|
||||
supported by BFD do not provide identical facilities, and information
|
||||
which can be described in one form has nowhere to go in another format.
|
||||
One example of this is alignment information in `b.out'. There is
|
||||
nowhere in an `a.out' format file to store alignment information on the
|
||||
contained data, so when a file is linked from `b.out' and an `a.out'
|
||||
image is produced, alignment information will not propagate to the
|
||||
output file. (The linker will still use the alignment information
|
||||
internally, so the link is performed correctly).
|
||||
|
||||
Another example is COFF section names. COFF files may contain an
|
||||
unlimited number of sections, each one with a textual section name. If
|
||||
the target of the link is a format which does not have many sections
|
||||
(e.g., `a.out') or has sections without names (e.g., the Oasys format),
|
||||
the link cannot be done simply. You can circumvent this problem by
|
||||
describing the desired input-to-output section mapping with the linker
|
||||
command language.
|
||||
|
||||
*Information can be lost during canonicalization.* The BFD internal
|
||||
canonical form of the external formats is not exhaustive; there are
|
||||
structures in input formats for which there is no direct representation
|
||||
internally. This means that the BFD back ends cannot maintain all
|
||||
possible data richness through the transformation between external to
|
||||
internal and back to external formats.
|
||||
|
||||
This limitation is only a problem when an application reads one
|
||||
format and writes another. Each BFD back end is responsible for
|
||||
maintaining as much data as possible, and the internal BFD canonical
|
||||
form has structures which are opaque to the BFD core, and exported only
|
||||
to the back ends. When a file is read in one format, the canonical form
|
||||
is generated for BFD and the application. At the same time, the back
|
||||
end saves away any information which may otherwise be lost. If the data
|
||||
is then written back in the same format, the back end routine will be
|
||||
able to use the canonical form provided by the BFD core as well as the
|
||||
information it prepared earlier. Since there is a great deal of
|
||||
commonality between back ends, there is no information lost when
|
||||
linking or copying big endian COFF to little endian COFF, or `a.out' to
|
||||
`b.out'. When a mixture of formats is linked, the information is only
|
||||
lost from the files whose format differs from the destination.
|
||||
|
||||
|
||||
File: ld.info, Node: Canonical format, Prev: BFD information loss, Up: BFD outline
|
||||
|
||||
The BFD canonical object-file format
|
||||
------------------------------------
|
||||
|
||||
The greatest potential for loss of information occurs when there is
|
||||
the least overlap between the information provided by the source
|
||||
format, that stored by the canonical format, and that needed by the
|
||||
destination format. A brief description of the canonical form may help
|
||||
you understand which kinds of data you can count on preserving across
|
||||
conversions.
|
||||
|
||||
*files*
|
||||
Information stored on a per-file basis includes target machine
|
||||
architecture, particular implementation format type, a demand
|
||||
pageable bit, and a write protected bit. Information like Unix
|
||||
magic numbers is not stored here--only the magic numbers' meaning,
|
||||
so a `ZMAGIC' file would have both the demand pageable bit and the
|
||||
write protected text bit set. The byte order of the target is
|
||||
stored on a per-file basis, so that big- and little-endian object
|
||||
files may be used with one another.
|
||||
|
||||
*sections*
|
||||
Each section in the input file contains the name of the section,
|
||||
the section's original address in the object file, size and
|
||||
alignment information, various flags, and pointers into other BFD
|
||||
data structures.
|
||||
|
||||
*symbols*
|
||||
Each symbol contains a pointer to the information for the object
|
||||
file which originally defined it, its name, its value, and various
|
||||
flag bits. When a BFD back end reads in a symbol table, it
|
||||
relocates all symbols to make them relative to the base of the
|
||||
section where they were defined. Doing this ensures that each
|
||||
symbol points to its containing section. Each symbol also has a
|
||||
varying amount of hidden private data for the BFD back end. Since
|
||||
the symbol points to the original file, the private data format
|
||||
for that symbol is accessible. `ld' can operate on a collection
|
||||
of symbols of wildly different formats without problems.
|
||||
|
||||
Normal global and simple local symbols are maintained on output,
|
||||
so an output file (no matter its format) will retain symbols
|
||||
pointing to functions and to global, static, and common variables.
|
||||
Some symbol information is not worth retaining; in `a.out', type
|
||||
information is stored in the symbol table as long symbol names.
|
||||
This information would be useless to most COFF debuggers; the
|
||||
linker has command line switches to allow users to throw it away.
|
||||
|
||||
There is one word of type information within the symbol, so if the
|
||||
format supports symbol type information within symbols (for
|
||||
example, COFF, IEEE, Oasys) and the type is simple enough to fit
|
||||
within one word (nearly everything but aggregates), the
|
||||
information will be preserved.
|
||||
|
||||
*relocation level*
|
||||
Each canonical BFD relocation record contains a pointer to the
|
||||
symbol to relocate to, the offset of the data to relocate, the
|
||||
section the data is in, and a pointer to a relocation type
|
||||
descriptor. Relocation is performed by passing messages through
|
||||
the relocation type descriptor and the symbol pointer. Therefore,
|
||||
relocations can be performed on output data using a relocation
|
||||
method that is only available in one of the input formats. For
|
||||
instance, Oasys provides a byte relocation format. A relocation
|
||||
record requesting this relocation type would point indirectly to a
|
||||
routine to perform this, so the relocation may be performed on a
|
||||
byte being written to a 68k COFF file, even though 68k COFF has no
|
||||
such relocation type.
|
||||
|
||||
*line numbers*
|
||||
Object formats can contain, for debugging purposes, some form of
|
||||
mapping between symbols, source line numbers, and addresses in the
|
||||
output file. These addresses have to be relocated along with the
|
||||
symbol information. Each symbol with an associated list of line
|
||||
number records points to the first record of the list. The head
|
||||
of a line number list consists of a pointer to the symbol, which
|
||||
allows finding out the address of the function whose line number
|
||||
is being described. The rest of the list is made up of pairs:
|
||||
offsets into the section and line numbers. Any format which can
|
||||
simply derive this information can pass it successfully between
|
||||
formats (COFF, IEEE and Oasys).
|
||||
|
||||
|
||||
File: ld.info, Node: MRI, Next: Index, Prev: BFD, Up: Top
|
||||
|
||||
MRI Compatible Script Files
|
||||
***************************
|
||||
|
||||
To aid users making the transition to GNU `ld' from the MRI linker,
|
||||
`ld' can use MRI compatible linker scripts as an alternative to the
|
||||
more general-purpose linker scripting language described in *Note
|
||||
Command Language: Commands. MRI compatible linker scripts have a much
|
||||
simpler command set than the scripting language otherwise used with
|
||||
`ld'. GNU `ld' supports the most commonly used MRI linker commands;
|
||||
these commands are described here.
|
||||
|
||||
In general, MRI scripts aren't of much use with the `a.out' object
|
||||
file format, since it only has three sections and MRI scripts lack some
|
||||
features to make use of them.
|
||||
|
||||
You can specify a file containing an MRI-compatible script using the
|
||||
`-c' command-line option.
|
||||
|
||||
Each command in an MRI-compatible script occupies its own line; each
|
||||
command line starts with the keyword that identifies the command (though
|
||||
blank lines are also allowed for punctuation). If a line of an
|
||||
MRI-compatible script begins with an unrecognized keyword, `ld' issues
|
||||
a warning message, but continues processing the script.
|
||||
|
||||
Lines beginning with `*' are comments.
|
||||
|
||||
You can write these commands using all upper-case letters, or all
|
||||
lower case; for example, `chip' is the same as `CHIP'. The following
|
||||
list shows only the upper-case form of each command.
|
||||
|
||||
`ABSOLUTE SECNAME'
|
||||
`ABSOLUTE SECNAME, SECNAME, ... SECNAME'
|
||||
Normally, `ld' includes in the output file all sections from all
|
||||
the input files. However, in an MRI-compatible script, you can
|
||||
use the `ABSOLUTE' command to restrict the sections that will be
|
||||
present in your output program. If the `ABSOLUTE' command is used
|
||||
at all in a script, then only the sections named explicitly in
|
||||
`ABSOLUTE' commands will appear in the linker output. You can
|
||||
still use other input sections (whatever you select on the command
|
||||
line, or using `LOAD') to resolve addresses in the output file.
|
||||
|
||||
`ALIAS OUT-SECNAME, IN-SECNAME'
|
||||
Use this command to place the data from input section IN-SECNAME
|
||||
in a section called OUT-SECNAME in the linker output file.
|
||||
|
||||
IN-SECNAME may be an integer.
|
||||
|
||||
`BASE EXPRESSION'
|
||||
Use the value of EXPRESSION as the lowest address (other than
|
||||
absolute addresses) in the output file.
|
||||
|
||||
`CHIP EXPRESSION'
|
||||
`CHIP EXPRESSION, EXPRESSION'
|
||||
This command does nothing; it is accepted only for compatibility.
|
||||
|
||||
`END'
|
||||
This command does nothing whatever; it's only accepted for
|
||||
compatibility.
|
||||
|
||||
`FORMAT OUTPUT-FORMAT'
|
||||
Similar to the `OUTPUT_FORMAT' command in the more general linker
|
||||
language, but restricted to one of these output formats:
|
||||
1. S-records, if OUTPUT-FORMAT is `S'
|
||||
|
||||
2. IEEE, if OUTPUT-FORMAT is `IEEE'
|
||||
|
||||
3. COFF (the `coff-m68k' variant in BFD), if OUTPUT-FORMAT is
|
||||
`COFF'
|
||||
|
||||
`LIST ANYTHING...'
|
||||
Print (to the standard output file) a link map, as produced by the
|
||||
`ld' command-line option `-M'.
|
||||
|
||||
The keyword `LIST' may be followed by anything on the same line,
|
||||
with no change in its effect.
|
||||
|
||||
`LOAD FILENAME'
|
||||
`LOAD FILENAME, FILENAME, ... FILENAME'
|
||||
Include one or more object file FILENAME in the link; this has the
|
||||
same effect as specifying FILENAME directly on the `ld' command
|
||||
line.
|
||||
|
||||
`NAME OUTPUT-NAME'
|
||||
OUTPUT-NAME is the name for the program produced by `ld'; the
|
||||
MRI-compatible command `NAME' is equivalent to the command-line
|
||||
option `-o' or the general script language command `OUTPUT'.
|
||||
|
||||
`ORDER SECNAME, SECNAME, ... SECNAME'
|
||||
`ORDER SECNAME SECNAME SECNAME'
|
||||
Normally, `ld' orders the sections in its output file in the order
|
||||
in which they first appear in the input files. In an
|
||||
MRI-compatible script, you can override this ordering with the
|
||||
`ORDER' command. The sections you list with `ORDER' will appear
|
||||
first in your output file, in the order specified.
|
||||
|
||||
`PUBLIC NAME=EXPRESSION'
|
||||
`PUBLIC NAME,EXPRESSION'
|
||||
`PUBLIC NAME EXPRESSION'
|
||||
Supply a value (EXPRESSION) for external symbol NAME used in the
|
||||
linker input files.
|
||||
|
||||
`SECT SECNAME, EXPRESSION'
|
||||
`SECT SECNAME=EXPRESSION'
|
||||
`SECT SECNAME EXPRESSION'
|
||||
You can use any of these three forms of the `SECT' command to
|
||||
specify the start address (EXPRESSION) for section SECNAME. If
|
||||
you have more than one `SECT' statement for the same SECNAME, only
|
||||
the *first* sets the start address.
|
||||
|
||||
|
||||
File: ld.info, Node: Index, Prev: MRI, Up: Top
|
||||
|
||||
Index
|
||||
*****
|
||||
|
||||
* Menu:
|
||||
|
||||
* ": Symbols.
|
||||
* *( COMMON ): Section Placement.
|
||||
* *(SECTION): Section Placement.
|
||||
* -help: Options.
|
||||
* -version: Options.
|
||||
* -AARCH: Options.
|
||||
* -b FORMAT: Options.
|
||||
* -Bstatic: Options.
|
||||
* -c MRI-CMDFILE: Options.
|
||||
* -d: Options.
|
||||
* -dc: Options.
|
||||
* -defsym SYMBOL=EXP: Options.
|
||||
* -dp: Options.
|
||||
* -e ENTRY: Options.
|
||||
* -F: Options.
|
||||
* -format: Options.
|
||||
* -g: Options.
|
||||
* -G: Options.
|
||||
* -i: Options.
|
||||
* -lARCHIVE: Options.
|
||||
* -LDIR: Options.
|
||||
* -M: Options.
|
||||
* -m EMULATION: Options.
|
||||
* -Map: Options.
|
||||
* -N: Options.
|
||||
* -n: Options.
|
||||
* -noinhibit-exec: Options.
|
||||
* -o OUTPUT: Options.
|
||||
* -oformat: Options.
|
||||
* -r: Options.
|
||||
* -R FILE: Options.
|
||||
* -relax: Options.
|
||||
* -s: Options.
|
||||
* -S: Options.
|
||||
* -t: Options.
|
||||
* -T SCRIPT: Options.
|
||||
* -Tbss ORG: Options.
|
||||
* -Tdata ORG: Options.
|
||||
* -Ttext ORG: Options.
|
||||
* -u SYMBOL: Options.
|
||||
* -Ur: Options.
|
||||
* -v: Options.
|
||||
* -V: Options.
|
||||
* -warn-comon: Options.
|
||||
* -x: Options.
|
||||
* -X: Options.
|
||||
* -ySYMBOL: Options.
|
||||
* .: Location Counter.
|
||||
* 0x: Integers.
|
||||
* ;: Assignment.
|
||||
* =FILL: Section Options.
|
||||
* >REGION: Section Options.
|
||||
* ABSOLUTE (MRI): MRI.
|
||||
* ALIAS (MRI): MRI.
|
||||
* BASE (MRI): MRI.
|
||||
* CHIP (MRI): MRI.
|
||||
* END (MRI): MRI.
|
||||
* FORMAT (MRI): MRI.
|
||||
* LIST (MRI): MRI.
|
||||
* LOAD (MRI): MRI.
|
||||
* NAME (MRI): MRI.
|
||||
* ORDER (MRI): MRI.
|
||||
* PUBLIC (MRI): MRI.
|
||||
* SECT (MRI): MRI.
|
||||
* FILENAME: Section Placement.
|
||||
* FILENAME(SECTION): Section Placement.
|
||||
* SYMBOL = EXPRESSION ;: Section Data Expressions.
|
||||
* SYMBOL F= EXPRESSION ;: Section Data Expressions.
|
||||
* absolute and relocatable symbols: Assignment.
|
||||
* ABSOLUTE(EXP): Arithmetic Functions.
|
||||
* ADDR(SECTION): Arithmetic Functions.
|
||||
* ALIGN(EXP): Arithmetic Functions.
|
||||
* aligning sections: Section Options.
|
||||
* allocating memory: MEMORY.
|
||||
* architectures: Options.
|
||||
* architectures available: BFD.
|
||||
* archive files, from cmd line: Options.
|
||||
* arithmetic: Expressions.
|
||||
* arithmetic operators: Operators.
|
||||
* assignment in scripts: Assignment.
|
||||
* assignment, in section defn: Section Data Expressions.
|
||||
* back end: BFD.
|
||||
* BFD canonical format: Canonical format.
|
||||
* BFD requirements: BFD.
|
||||
* binary input files: Option Commands.
|
||||
* binary input format: Options.
|
||||
* BLOCK(ALIGN): Section Options.
|
||||
* BYTE(EXPRESSION): Section Data Expressions.
|
||||
* combining symbols, warnings on: Options.
|
||||
* command files: Commands.
|
||||
* command line: Options.
|
||||
* commands, fundamental: Scripts.
|
||||
* comments: Scripts.
|
||||
* common allocation: Option Commands.
|
||||
* common allocation: Options.
|
||||
* commons in output: Section Placement.
|
||||
* compatibility, MRI: Options.
|
||||
* constructors: Options.
|
||||
* contents of a section: Section Placement.
|
||||
* CREATE_OBJECT_SYMBOLS: Section Data Expressions.
|
||||
* current output location: Location Counter.
|
||||
* decimal integers: Integers.
|
||||
* default input format: Environment.
|
||||
* DEFINED(SYMBOL): Arithmetic Functions.
|
||||
* deleting local symbols: Options.
|
||||
* direct output: Section Data Expressions.
|
||||
* discontinuous memory: MEMORY.
|
||||
* dot: Location Counter.
|
||||
* emulation: Options.
|
||||
* entry point, defaults: Entry Point.
|
||||
* entry point, from command line: Options.
|
||||
* ENTRY(SYMBOL): Entry Point.
|
||||
* expression evaluation order: Evaluation.
|
||||
* expression syntax: Expressions.
|
||||
* expression, absolute: Arithmetic Functions.
|
||||
* expressions in a section: Section Data Expressions.
|
||||
* filename symbols: Section Data Expressions.
|
||||
* files and sections, section defn: Section Placement.
|
||||
* files, including in output sections: Section Placement.
|
||||
* fill pattern, entire section: Section Options.
|
||||
* FILL(EXPRESSION): Section Data Expressions.
|
||||
* first input file: Option Commands.
|
||||
* first instruction: Entry Point.
|
||||
* FLOAT: Option Commands.
|
||||
* FORCE_COMMON_ALLOCATION: Option Commands.
|
||||
* format, output file: Option Commands.
|
||||
* formats available: BFD.
|
||||
* functions in expression language: Arithmetic Functions.
|
||||
* fundamental script commands: Scripts.
|
||||
* GNU linker: Overview.
|
||||
* GNUTARGET: Option Commands.
|
||||
* GNUTARGET: Environment.
|
||||
* H8/300 support: H8/300.
|
||||
* header size: Arithmetic Functions.
|
||||
* help: Options.
|
||||
* hexadecimal integers: Integers.
|
||||
* holes: Location Counter.
|
||||
* holes, filling: Section Data Expressions.
|
||||
* i960 support: i960.
|
||||
* incremental link: Options.
|
||||
* INPUT ( FILES ): Option Commands.
|
||||
* input file format: Option Commands.
|
||||
* input filename symbols: Section Data Expressions.
|
||||
* input files, displaying: Options.
|
||||
* input files, section defn: Section Placement.
|
||||
* input format: Options.
|
||||
* input format: Options.
|
||||
* input sections to output section: Section Placement.
|
||||
* integer notation: Integers.
|
||||
* integer suffixes: Integers.
|
||||
* internal object-file format: Canonical format.
|
||||
* K and M integer suffixes: Integers.
|
||||
* l =: MEMORY.
|
||||
* L, deleting symbols beginning: Options.
|
||||
* layout of output file: Scripts.
|
||||
* lazy evaluation: Evaluation.
|
||||
* len =: MEMORY.
|
||||
* LENGTH =: MEMORY.
|
||||
* link map: Options.
|
||||
* link map: Options.
|
||||
* local symbols, deleting: Options.
|
||||
* location counter: Location Counter.
|
||||
* LONG(EXPRESSION): Section Data Expressions.
|
||||
* M and K integer suffixes: Integers.
|
||||
* machine architecture, output: Option Commands.
|
||||
* machine dependencies: Machine Dependent.
|
||||
* MEMORY: MEMORY.
|
||||
* memory region attributes: MEMORY.
|
||||
* memory regions and sections: Section Options.
|
||||
* MRI compatibility: MRI.
|
||||
* names: Symbols.
|
||||
* naming memory regions: MEMORY.
|
||||
* naming output sections: Section Definition.
|
||||
* naming the output file: Options.
|
||||
* naming the output file: Option Commands.
|
||||
* negative integers: Integers.
|
||||
* NEXT(EXP): Arithmetic Functions.
|
||||
* NMAGIC: Options.
|
||||
* NOFLOAT: Option Commands.
|
||||
* NOLOAD: Section Options.
|
||||
* Non constant expression: Assignment.
|
||||
* o =: MEMORY.
|
||||
* object file management: BFD.
|
||||
* object files: Options.
|
||||
* object size: Options.
|
||||
* octal integers: Integers.
|
||||
* OMAGIC: Options.
|
||||
* opening object files: BFD outline.
|
||||
* Operators for arithmetic: Operators.
|
||||
* options: Options.
|
||||
* org =: MEMORY.
|
||||
* ORIGIN =: MEMORY.
|
||||
* OUTPUT ( FILENAME ): Option Commands.
|
||||
* output file after errors: Options.
|
||||
* output file layout: Scripts.
|
||||
* OUTPUT_ARCH ( BFDNAME ): Option Commands.
|
||||
* OUTPUT_FORMAT ( BFDNAME ): Option Commands.
|
||||
* partial link: Options.
|
||||
* path for libraries: Option Commands.
|
||||
* precedence in expressions: Operators.
|
||||
* prevent unnecessary loading: Section Options.
|
||||
* quoted symbol names: Symbols.
|
||||
* read-only text: Options.
|
||||
* read/write from cmd line: Options.
|
||||
* regions of memory: MEMORY.
|
||||
* relaxing addressing modes: Options.
|
||||
* relaxing on H8/300: H8/300.
|
||||
* relocatable and absolute symbols: Assignment.
|
||||
* relocatable output: Options.
|
||||
* requirements for BFD: BFD.
|
||||
* rounding up location counter: Arithmetic Functions.
|
||||
* scaled integers: Integers.
|
||||
* script files: Options.
|
||||
* search directory, from cmd line: Options.
|
||||
* search path, libraries: Option Commands.
|
||||
* SEARCH_DIR ( PATH ): Option Commands.
|
||||
* section address: Arithmetic Functions.
|
||||
* section address: Section Options.
|
||||
* section alignment: Section Options.
|
||||
* section definition: Section Definition.
|
||||
* section defn, full syntax: Section Options.
|
||||
* section fill pattern: Section Options.
|
||||
* section size: Arithmetic Functions.
|
||||
* section start: Section Options.
|
||||
* section, assigning to memory region: Section Options.
|
||||
* SECTIONS: SECTIONS.
|
||||
* segment origins, cmd line: Options.
|
||||
* semicolon: Assignment.
|
||||
* SHORT(EXPRESSION): Section Data Expressions.
|
||||
* SIZEOF(SECTION): Arithmetic Functions.
|
||||
* SIZEOF_HEADERS: Arithmetic Functions.
|
||||
* sizeof_headers: Arithmetic Functions.
|
||||
* standard Unix system: Options.
|
||||
* start address, section: Section Options.
|
||||
* start of execution: Entry Point.
|
||||
* STARTUP ( FILENAME ): Option Commands.
|
||||
* strip all symbols: Options.
|
||||
* strip debugger symbols: Options.
|
||||
* suffixes for integers: Integers.
|
||||
* symbol defaults: Arithmetic Functions.
|
||||
* symbol definition, scripts: Assignment.
|
||||
* symbol names: Symbols.
|
||||
* symbol tracing: Options.
|
||||
* symbol-only input: Options.
|
||||
* symbols, from command line: Options.
|
||||
* symbols, relocatable and absolute: Assignment.
|
||||
* synthesizing linker: Options.
|
||||
* synthesizing on H8/300: H8/300.
|
||||
* TARGET ( FORMAT ): Option Commands.
|
||||
* unallocated address, next: Arithmetic Functions.
|
||||
* undefined symbol: Options.
|
||||
* uninitialized data: Section Placement.
|
||||
* unspecified memory: Section Data Expressions.
|
||||
* usage: Options.
|
||||
* variables, defining: Assignment.
|
||||
* verbose: Options.
|
||||
* version: Options.
|
||||
* version: Options.
|
||||
* warnings, on combining symbols: Options.
|
||||
* what is this?: Overview.
|
||||
|
||||
|
Loading…
Reference in a new issue