-@c Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2003
+@c Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2008
@c Free Software Foundation, Inc.
@c This is part of the GAS manual.
@c For copying conditions, see the file as.texinfo.
* ARM Directives:: ARM Machine Directives
* ARM Opcodes:: Opcodes
* ARM Mapping Symbols:: Mapping Symbols
+* ARM Unwinding Tutorial:: Unwinding
@end menu
@node ARM Options
@code{arm7500fe},
@code{arm7t},
@code{arm7tdmi},
+@code{arm7tdmi-s},
@code{arm8},
@code{arm810},
@code{strongarm},
@code{arm922t},
@code{arm940t},
@code{arm9tdmi},
+@code{fa526} (Faraday FA526 processor),
+@code{fa626} (Faraday FA626 processor),
@code{arm9e},
+@code{arm926e},
+@code{arm926ej-s},
@code{arm946e-r0},
@code{arm946e},
+@code{arm946e-s},
@code{arm966e-r0},
@code{arm966e},
+@code{arm966e-s},
+@code{arm968e-s},
@code{arm10t},
+@code{arm10tdmi},
@code{arm10e},
@code{arm1020},
@code{arm1020t},
-@code{arm1020e},
-@code{arm1136js},
-@code{arm1136jfs},
+@code{arm1020e},
+@code{arm1022e},
+@code{arm1026ej-s},
+@code{fa626te} (Faraday FA626TE processor),
+@code{fa726te} (Faraday FA726TE processor),
+@code{arm1136j-s},
+@code{arm1136jf-s},
+@code{arm1156t2-s},
+@code{arm1156t2f-s},
+@code{arm1176jz-s},
+@code{arm1176jzf-s},
+@code{mpcore},
+@code{mpcorenovfp},
+@code{cortex-a8},
+@code{cortex-a9},
+@code{cortex-r4},
+@code{cortex-m3},
@code{ep9312} (ARM920 with Cirrus Maverick coprocessor),
@code{i80200} (Intel XScale processor)
@code{iwmmxt} (Intel(r) XScale processor with Wireless MMX(tm) technology coprocessor)
@code{armv5texp},
@code{armv6},
@code{armv6j},
+@code{armv6k},
+@code{armv6z},
+@code{armv6zk},
+@code{armv7},
+@code{armv7-a},
+@code{armv7-r},
+@code{armv7-m},
@code{iwmmxt}
and
@code{xscale}.
@code{vfp10-r0},
@code{vfp9},
@code{vfpxd},
+@code{vfpv2}
+@code{vfpv3}
+@code{vfpv3-d16}
@code{arm1020t},
@code{arm1020e},
-@code{arm1136jfs}
+@code{arm1136jf-s},
+@code{maverick}
and
-@code{maverick}.
+@code{neon}.
In addition to determining which instructions are assembled, this option
also affects the way in which the @code{.double} assembler directive behaves
and
@code{hard}.
+@cindex @code{-eabi=} command line option, ARM
+@item -meabi=@var{ver}
+This option specifies which EABI version the produced object files should
+conform to.
+The following values are recognized:
+@code{gnu},
+@code{4}
+and
+@code{5}.
+
@cindex @code{-EB} command line option, ARM
@item -EB
This option specifies that the output generated by the assembler should
This option specifies that the output of the assembler should be marked
as position-independent code (PIC).
-@cindex @code{-moabi} command line option, ARM
-@item -moabi
-This indicates that the code should be assembled using the old ARM ELF
-conventions, based on a beta release release of the ARM-ELF
-specifications, rather than the default conventions which are based on
-the final release of the ARM-ELF specifications.
+@cindex @code{--fix-v4bx} command line option, ARM
+@item --fix-v4bx
+Allow @code{BX} instructions in ARMv4 code. This is intended for use with
+the linker option of the same name.
@end table
@menu
* ARM-Chars:: Special Characters
* ARM-Regs:: Register Names
+* ARM-Relocations:: Relocations
@end menu
@node ARM-Chars
@cindex ARM floating point (@sc{ieee})
The ARM family uses @sc{ieee} floating-point numbers.
+@node ARM-Relocations
+@subsection ARM relocation generation
+
+@cindex data relocations, ARM
+@cindex ARM data relocations
+Specific data relocations can be generated by putting the relocation name
+in parentheses after the symbol name. For example:
+
+@smallexample
+ .word foo(TARGET1)
+@end smallexample
+
+This will generate an @samp{R_ARM_TARGET1} relocation against the symbol
+@var{foo}.
+The following relocations are supported:
+@code{GOT},
+@code{GOTOFF},
+@code{TARGET1},
+@code{TARGET2},
+@code{SBREL},
+@code{TLSGD},
+@code{TLSLDM},
+@code{TLSLDO},
+@code{GOTTPOFF}
+and
+@code{TPOFF}.
+
+For compatibility with older toolchains the assembler also accepts
+@code{(PLT)} after branch targets. This will generate the deprecated
+@samp{R_ARM_PLT32} relocation.
+@cindex MOVW and MOVT relocations, ARM
+Relocations for @samp{MOVW} and @samp{MOVT} instructions can be generated
+by prefixing the value with @samp{#:lower16:} and @samp{#:upper16}
+respectively. For example to load the 32-bit address of foo into r0:
+
+@smallexample
+ MOVW r0, #:lower16:foo
+ MOVT r0, #:upper16:foo
+@end smallexample
@node ARM Directives
@section ARM Machine Directives
@cindex @code{unreq} directive, ARM
@item .unreq @var{alias-name}
This undefines a register alias which was previously defined using the
-@code{req} directive. For example:
+@code{req}, @code{dn} or @code{qn} directives. For example:
@smallexample
foo .req r0
be used to delete builtin in register name aliases (eg 'r0'). This
should only be done if it is really necessary.
+@cindex @code{dn} and @code{qn} directives, ARM
+@item @var{name} .dn @var{register name} [@var{.type}] [[@var{index}]]
+@item @var{name} .qn @var{register name} [@var{.type}] [[@var{index}]]
+
+The @code{dn} and @code{qn} directives are used to create typed
+and/or indexed register aliases for use in Advanced SIMD Extension
+(Neon) instructions. The former should be used to create aliases
+of double-precision registers, and the latter to create aliases of
+quad-precision registers.
+
+If these directives are used to create typed aliases, those aliases can
+be used in Neon instructions instead of writing types after the mnemonic
+or after each operand. For example:
+
+@smallexample
+ x .dn d2.f32
+ y .dn d3.f32
+ z .dn d4.f32[1]
+ vmul x,y,z
+@end smallexample
+
+This is equivalent to writing the following:
+
+@smallexample
+ vmul.f32 d2,d3,d4[1]
+@end smallexample
+
+Aliases created using @code{dn} or @code{qn} can be destroyed using
+@code{unreq}.
+
@cindex @code{code} directive, ARM
@item .code @code{[16|32]}
This directive selects the instruction set being generated. The value 16
interworking is not going to be performed. The presence of this
directive also implies @code{.thumb}
+This directive is not neccessary when generating EABI objects. On these
+targets the encoding is implicit when generating Thumb code.
+
@cindex @code{thumb_set} directive, ARM
@item .thumb_set
This performs the equivalent of a @code{.set} directive in that it
@item .pool
This is a synonym for .ltorg.
+@anchor{arm_fnstart}
+@cindex @code{.fnstart} directive, ARM
+@item .fnstart
+Marks the start of a function with an unwind table entry.
+
+@anchor{arm_fnend}
+@cindex @code{.fnend} directive, ARM
+@item .fnend
+Marks the end of a function with an unwind table entry. The unwind index
+table entry is created when this directive is processed.
+
+If no personality routine has been specified then standard personality
+routine 0 or 1 will be used, depending on the number of unwind opcodes
+required.
+
+@cindex @code{.cantunwind} directive, ARM
+@item .cantunwind
+Prevents unwinding through the current function. No personality routine
+or exception table data is required or permitted.
+
+@cindex @code{.personality} directive, ARM
+@item .personality @var{name}
+Sets the personality routine for the current function to @var{name}.
+
+@cindex @code{.personalityindex} directive, ARM
+@item .personalityindex @var{index}
+Sets the personality routine for the current function to the EABI standard
+routine number @var{index}
+
+@cindex @code{.handlerdata} directive, ARM
+@item .handlerdata
+Marks the end of the current function, and the start of the exception table
+entry for that function. Anything between this directive and the
+@code{.fnend} directive will be added to the exception table entry.
+
+Must be preceded by a @code{.personality} or @code{.personalityindex}
+directive.
+
+@anchor{arm_save}
+@cindex @code{.save} directive, ARM
+@item .save @var{reglist}
+Generate unwinder annotations to restore the registers in @var{reglist}.
+The format of @var{reglist} is the same as the corresponding store-multiple
+instruction.
+
+@smallexample
+@exdent @emph{core registers}
+ .save @{r4, r5, r6, lr@}
+ stmfd sp!, @{r4, r5, r6, lr@}
+@exdent @emph{FPA registers}
+ .save f4, 2
+ sfmfd f4, 2, [sp]!
+@exdent @emph{VFP registers}
+ .save @{d8, d9, d10@}
+ fstmdx sp!, @{d8, d9, d10@}
+@exdent @emph{iWMMXt registers}
+ .save @{wr10, wr11@}
+ wstrd wr11, [sp, #-8]!
+ wstrd wr10, [sp, #-8]!
+or
+ .save wr11
+ wstrd wr11, [sp, #-8]!
+ .save wr10
+ wstrd wr10, [sp, #-8]!
+@end smallexample
+
+@cindex @code{.vsave} directive, ARM
+@item .vsave @var{vfp-reglist}
+Generate unwinder annotations to restore the VFP registers in @var{vfp-reglist}
+using FLDMD. Also works for VFPv3 registers
+that are to be restored using VLDM.
+The format of @var{vfp-reglist} is the same as the corresponding store-multiple
+instruction.
+
+@smallexample
+@exdent @emph{VFP registers}
+ .vsave @{d8, d9, d10@}
+ fstmdd sp!, @{d8, d9, d10@}
+@exdent @emph{VFPv3 registers}
+ .vsave @{d15, d16, d17@}
+ vstm sp!, @{d15, d16, d17@}
+@end smallexample
+
+Since FLDMX and FSTMX are now deprecated, this directive should be
+used in favour of @code{.save} for saving VFP registers for ARMv6 and above.
+
+@anchor{arm_pad}
+@cindex @code{.pad} directive, ARM
+@item .pad #@var{count}
+Generate unwinder annotations for a stack adjustment of @var{count} bytes.
+A positive value indicates the function prologue allocated stack space by
+decrementing the stack pointer.
+
+@anchor{arm_movsp}
+@cindex @code{.movsp} directive, ARM
+@item .movsp @var{reg} [, #@var{offset}]
+Tell the unwinder that @var{reg} contains an offset from the current
+stack pointer. If @var{offset} is not specified then it is assumed to be
+zero.
+
+@anchor{arm_setfp}
+@cindex @code{.setfp} directive, ARM
+@item .setfp @var{fpreg}, @var{spreg} [, #@var{offset}]
+Make all unwinder annotations relaive to a frame pointer. Without this
+the unwinder will use offsets from the stack pointer.
+
+The syntax of this directive is the same as the @code{sub} or @code{mov}
+instruction used to set the frame pointer. @var{spreg} must be either
+@code{sp} or mentioned in a previous @code{.movsp} directive.
+
+@smallexample
+.movsp ip
+mov ip, sp
+@dots{}
+.setfp fp, ip, #4
+sub fp, ip, #4
+@end smallexample
+
+@cindex @code{.unwind_raw} directive, ARM
+@item .raw @var{offset}, @var{byte1}, @dots{}
+Insert one of more arbitary unwind opcode bytes, which are known to adjust
+the stack pointer by @var{offset} bytes.
+
+For example @code{.unwind_raw 4, 0xb1, 0x01} is equivalent to
+@code{.save @{r0@}}
+
+@cindex @code{.cpu} directive, ARM
+@item .cpu @var{name}
+Select the target processor. Valid values for @var{name} are the same as
+for the @option{-mcpu} commandline option.
+
+@cindex @code{.arch} directive, ARM
+@item .arch @var{name}
+Select the target architecture. Valid values for @var{name} are the same as
+for the @option{-march} commandline option.
+
+@cindex @code{.object_arch} directive, ARM
+@item .object_arch @var{name}
+Override the architecture recorded in the EABI object attribute section.
+Valid values for @var{name} are the same as for the @code{.arch} directive.
+Typically this is useful when code uses runtime detection of CPU features.
+
+@cindex @code{.fpu} directive, ARM
+@item .fpu @var{name}
+Select the floating point unit to assemble for. Valid values for @var{name}
+are the same as for the @option{-mfpu} commandline option.
+
+@cindex @code{.eabi_attribute} directive, ARM
+@item .eabi_attribute @var{tag}, @var{value}
+Set the EABI object attribute number @var{tag} to @var{value}. The value
+is either a @code{number}, @code{"string"}, or @code{number, "string"}
+depending on the tag.
+
@end table
@node ARM Opcodes
dropped from the new EABI and so tools cannot rely upon their
presence.
+@node ARM Unwinding Tutorial
+@section Unwinding
+
+The ABI for the ARM Architecture specifies a standard format for
+exception unwind information. This information is used when an
+exception is thrown to determine where control should be transferred.
+In particular, the unwind information is used to determine which
+function called the function that threw the exception, and which
+function called that one, and so forth. This information is also used
+to restore the values of callee-saved registers in the function
+catching the exception.
+
+If you are writing functions in assembly code, and those functions
+call other functions that throw exceptions, you must use assembly
+pseudo ops to ensure that appropriate exception unwind information is
+generated. Otherwise, if one of the functions called by your assembly
+code throws an exception, the run-time library will be unable to
+unwind the stack through your assembly code and your program will not
+behave correctly.
+
+To illustrate the use of these pseudo ops, we will examine the code
+that G++ generates for the following C++ input:
+
+@verbatim
+void callee (int *);
+
+int
+caller ()
+{
+ int i;
+ callee (&i);
+ return i;
+}
+@end verbatim
+
+This example does not show how to throw or catch an exception from
+assembly code. That is a much more complex operation and should
+always be done in a high-level language, such as C++, that directly
+supports exceptions.
+
+The code generated by one particular version of G++ when compiling the
+example above is:
+
+@verbatim
+_Z6callerv:
+ .fnstart
+.LFB2:
+ @ Function supports interworking.
+ @ args = 0, pretend = 0, frame = 8
+ @ frame_needed = 1, uses_anonymous_args = 0
+ stmfd sp!, {fp, lr}
+ .save {fp, lr}
+.LCFI0:
+ .setfp fp, sp, #4
+ add fp, sp, #4
+.LCFI1:
+ .pad #8
+ sub sp, sp, #8
+.LCFI2:
+ sub r3, fp, #8
+ mov r0, r3
+ bl _Z6calleePi
+ ldr r3, [fp, #-8]
+ mov r0, r3
+ sub sp, fp, #4
+ ldmfd sp!, {fp, lr}
+ bx lr
+.LFE2:
+ .fnend
+@end verbatim
+
+Of course, the sequence of instructions varies based on the options
+you pass to GCC and on the version of GCC in use. The exact
+instructions are not important since we are focusing on the pseudo ops
+that are used to generate unwind information.
+
+An important assumption made by the unwinder is that the stack frame
+does not change during the body of the function. In particular, since
+we assume that the assembly code does not itself throw an exception,
+the only point where an exception can be thrown is from a call, such
+as the @code{bl} instruction above. At each call site, the same saved
+registers (including @code{lr}, which indicates the return address)
+must be located in the same locations relative to the frame pointer.
+
+The @code{.fnstart} (@pxref{arm_fnstart,,.fnstart pseudo op}) pseudo
+op appears immediately before the first instruction of the function
+while the @code{.fnend} (@pxref{arm_fnend,,.fnend pseudo op}) pseudo
+op appears immediately after the last instruction of the function.
+These pseudo ops specify the range of the function.
+
+Only the order of the other pseudos ops (e.g., @code{.setfp} or
+@code{.pad}) matters; their exact locations are irrelevant. In the
+example above, the compiler emits the pseudo ops with particular
+instructions. That makes it easier to understand the code, but it is
+not required for correctness. It would work just as well to emit all
+of the pseudo ops other than @code{.fnend} in the same order, but
+immediately after @code{.fnstart}.
+
+The @code{.save} (@pxref{arm_save,,.save pseudo op}) pseudo op
+indicates registers that have been saved to the stack so that they can
+be restored before the function returns. The argument to the
+@code{.save} pseudo op is a list of registers to save. If a register
+is ``callee-saved'' (as specified by the ABI) and is modified by the
+function you are writing, then your code must save the value before it
+is modified and restore the original value before the function
+returns. If an exception is thrown, the run-time library restores the
+values of these registers from their locations on the stack before
+returning control to the exception handler. (Of course, if an
+exception is not thrown, the function that contains the @code{.save}
+pseudo op restores these registers in the function epilogue, as is
+done with the @code{ldmfd} instruction above.)
+
+You do not have to save callee-saved registers at the very beginning
+of the function and you do not need to use the @code{.save} pseudo op
+immediately following the point at which the registers are saved.
+However, if you modify a callee-saved register, you must save it on
+the stack before modifying it and before calling any functions which
+might throw an exception. And, you must use the @code{.save} pseudo
+op to indicate that you have done so.
+
+The @code{.pad} (@pxref{arm_pad,,.pad}) pseudo op indicates a
+modification of the stack pointer that does not save any registers.
+The argument is the number of bytes (in decimal) that are subtracted
+from the stack pointer. (On ARM CPUs, the stack grows downwards, so
+subtracting from the stack pointer increases the size of the stack.)
+
+The @code{.setfp} (@pxref{arm_setfp,,.setfp pseudo op}) pseudo op
+indicates the register that contains the frame pointer. The first
+argument is the register that is set, which is typically @code{fp}.
+The second argument indicates the register from which the frame
+pointer takes its value. The third argument, if present, is the value
+(in decimal) added to the register specified by the second argument to
+compute the value of the frame pointer. You should not modify the
+frame pointer in the body of the function.
+
+If you do not use a frame pointer, then you should not use the
+@code{.setfp} pseudo op. If you do not use a frame pointer, then you
+should avoid modifying the stack pointer outside of the function
+prologue. Otherwise, the run-time library will be unable to find
+saved registers when it is unwinding the stack.
+
+The pseudo ops described above are sufficient for writing assembly
+code that calls functions which may throw exceptions. If you need to
+know more about the object-file format used to represent unwind
+information, you may consult the @cite{Exception Handling ABI for the
+ARM Architecture} available from @uref{http://infocenter.arm.com}.
projects / deliverable / binutils-gdb.git / blobdiff