Professional Documents
Culture Documents
IHI0044D Aaelf
IHI0044D Aaelf
IHI0044D Aaelf
Document number: ARM IHI 0044D, current through ABI release 2.08
Date of Issue: 28th October 2009
Abstract
This document describes the processor-specific definitions for ELF for the Application Binary Interface (ABI) for
the ARM architecture.
Keywords
Object files, file formats, linking, EABI, ELF
Please report defects in this specification to arm dot eabi at arm dot com.
Licence
THE TERMS OF YOUR ROYALTY FREE LIMITED LICENCE TO USE THIS ABI SPECIFICATION ARE GIVEN IN SECTION
1.4, Your licence to use this specification (ARM contract reference LEC-ELA-00081 V2.0). PLEASE READ THEM
CAREFULLY.
BY DOWNLOADING OR OTHERWISE USING THIS SPECIFICATION, YOU AGREE TO BE BOUND BY ALL OF ITS
TERMS. IF YOU DO NOT AGREE TO THIS, DO NOT DOWNLOAD OR USE THIS SPECIFICATION.
THIS ABI SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES (SEE SECTION 1.4 FOR DETAILS).
Proprietary notice
ARM, Thumb, RealView, ARM7TDMI and ARM9TDMI are registered trademarks of ARM Limited. The ARM logo
is a trademark of ARM Limited. ARM9, ARM926EJ-S, ARM946E-S, ARM1136J-S ARM1156T2F-S ARM1176JZ-S
Cortex, and Neon are trademarks of ARM Limited. All other products or services mentioned herein may be
trademarks of their respective owners.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 1 of 45
ELF for the ARM Architecture
Contents
1.2 References 6
1.5 Acknowledgements 8
2 SCOPE 9
3 PLATFORM STANDARDS 10
4 OBJECT FILES 15
4.1 Introduction 15
4.1.1 Registered Vendor Names 15
4.4 Sections 17
4.4.1 Special Section Indexes 17
4.4.2 Section Types 17
4.4.3 Section Attribute Flags 17
4.4.3.1 Merging of objects in sections with SHF_MERGE 17
4.4.4 Special Sections 18
4.4.5 Section Alignment 18
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 2 of 45
ELF for the ARM Architecture
4.7 Relocation 23
4.7.1 Relocation codes 23
4.7.1.1 Addends and PC-bias compensation 23
4.7.1.2 Relocation types 24
4.7.1.3 Static Data relocations 29
4.7.1.4 Static ARM relocations 29
4.7.1.5 Static Thumb16 relocations 32
4.7.1.6 Static Thumb32 relocations 33
4.7.1.7 Static miscellaneous relocations 34
4.7.1.8 Proxy generating relocations 34
4.7.1.9 Relocations for thread-local storage 35
4.7.1.10 Dynamic relocations 36
4.7.1.11 Deprecated relocations 37
4.7.1.12 Obsolete relocations 37
4.7.1.13 Private relocations 37
4.7.1.14 Unallocated relocations 37
4.7.2 Idempotency 38
5.1 Introduction 39
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 3 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 4 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 5 of 45
ELF for the ARM Architecture
D 28th October 2009 LS Added http://infocenter.arm.com/ references to the recently published [ARM
ARM] and the [ARMv5 ARM]; in §4.7.1.6 (Thumb relocations) cross-
referenced permitted veneer-generation. In §4.7.1.5, Table 4-12, extended
R_ARM_THM_PC8 to ADR as well as LDR(literal). Updated and tidied §5.2.1
and added §5.2.1.1 as a proposal for recording executable file attributes.
1.2 References
This document refers to, or is referred to by, the documents listed in the following table.
Ref Reference Title
AAELF ELF for the ARM Architecture (This document).
ARM ARM (From http://infocenter.arm.com/help/index.jsp, ARM DDI 0406: ARM Architecture Reference Manual
via links ARM architecture, Reference ARM v7-A and ARM v7-R edition
manuals)
ARM DDI 0403C: ARMv7-M Architecture Reference
(Registration required) Manual
ARMv5 ARM (As for ARM ARM; no registration needed) ARM DDI 0100I: ARMv5 Architecture Reference Manual
GDWARF http://www.eagercon.com/dwarf/dwarf3std.htm DWARF 3.0, the generic debug table format
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 6 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 7 of 45
ELF for the ARM Architecture
This Specification is owned by ARM or its licensors and is protected by copyright laws and international copyright
treaties as well as other intellectual property laws and treaties. The Specification is licensed not sold.
1. Subject to the provisions of Clauses 2 and 3, ARM hereby grants to LICENSEE, under any intellectual
property that is (i) owned or freely licensable by ARM without payment to unaffiliated third parties and (ii)
either embodied in the Specification or Necessary to copy or implement an applications binary interface
compliant with this Specification, a perpetual, non-exclusive, non-transferable, fully paid, worldwide limited
licence (without the right to sublicense) to use and copy this Specification solely for the purpose of
developing, having developed, manufacturing, having manufactured, offering to sell, selling, supplying or
otherwise distributing products which comply with the Specification.
2. THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES EXPRESS, IMPLIED OR STATUTORY,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF SATISFACTORY QUALITY, MERCHANTABILITY,
NONINFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSE. THE SPECIFICATION MAY INCLUDE
ERRORS. ARM RESERVES THE RIGHT TO INCORPORATE MODIFICATIONS TO THE SPECIFICATION IN
LATER REVISIONS OF IT, AND TO MAKE IMPROVEMENTS OR CHANGES IN THE SPECIFICATION OR THE
PRODUCTS OR TECHNOLOGIES DESCRIBED THEREIN AT ANY TIME.
3. This Licence shall immediately terminate and shall be unavailable to LICENSEE if LICENSEE or any party
affiliated to LICENSEE asserts any patents against ARM, ARM affiliates, third parties who have a valid
licence from ARM for the Specification, or any customers or distributors of any of them based upon a
claim that a LICENSEE (or LICENSEE affiliate) patent is Necessary to implement the Specification. In this
Licence; (i) “affiliate” means any entity controlling, controlled by or under common control with a party (in
fact or in law, via voting securities, management control or otherwise) and “affiliated” shall be construed
accordingly; (ii) “assert” means to allege infringement in legal or administrative proceedings, or
proceedings before any other competent trade, arbitral or international authority; (iii) “Necessary” means
with respect to any claims of any patent, those claims which, without the appropriate permission of the
patent owner, will be infringed when implementing the Specification because no alternative, commercially
reasonable, non-infringing way of implementing the Specification is known; and (iv) English law and the
jurisdiction of the English courts shall apply to all aspects of this Licence, its interpretation and
enforcement. The total liability of ARM and any of its suppliers and licensors under or in relation to this
Licence shall be limited to the greater of the amount actually paid by LICENSEE for the Specification or
US$10.00. The limitations, exclusions and disclaimers in this Licence shall apply to the maximum extent
allowed by applicable law.
ARM Contract reference LEC-ELA-00081 V2.0 AB/LS (9 March 2005)
1.5 Acknowledgements
This specification has been developed with the active support of the following organizations. In alphabetical order:
ARM, CodeSourcery, Intel, Metrowerks, Montavista, Nexus Electronics, PalmSource, Symbian, Texas
Instruments, and Wind River.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 8 of 45
ELF for the ARM Architecture
2 SCOPE
This specification provides the processor-specific definitions required by ELF [SCO-ELF] for ARM based systems.
The ELF specification is part of the larger System V ABI specification where it forms chapters 4 and 5. However,
the specification can be used in isolation as a generic object and executable format.
Section 3 of this document covers ELF related matters that are platform specific. Most of this material is related to
the Base Platform ABI.
Sections 4 and 5 of this document are structured to correspond to chapters 4 and 5 of the ELF specification.
Specifically:
Section 4 covers object files and relocations
Section 5 covers program loading and dynamic linking.
There are several drafts of the ELF specification on the SCO web site. This specification is based on the
December 2003 draft, which was the most recent stable draft at the time this specification was developed.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 9 of 45
ELF for the ARM Architecture
3 PLATFORM STANDARDS
When an executable file uses symbol versioning there is also a virtual table of versions. This is not represented in
the file (there is no corresponding file component). It contains a row for each distinct version defined by, and
needed by, this file.
Each version defined, and each version needed, by this file carries its row index in this virtual table, so the table
can be constructed on demand. Indexes 2, 3, 4, and so on, are local to this file. Indexes 0 and 1 have predefined
global meanings, as do indexes with the top bit (0x8000) set.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 10 of 45
ELF for the ARM Architecture
The version definition section defines a set of versions exported from this file and the successor relationships
among them.
Each version has a textual name, and two versions are the same if their names compare equal. Textual names
are represented by offsets into the associated string table section. Names that must be processed during dynamic
linking are also hashed using the standard ELF hash function [SCO-ELF].
Each version definition is linked to the next version definition via it vd_next field which contains the byte offset
from the start of this version definition to the start of the next one. Zero marks the end of the list.
Each symbol exported from this shared object refers, via an index in the version section, to one of these version
definitions. If bit 15 of the index is set, the symbol is hidden from static binding because it has an old version.
During static linking against this shared object, an undefined symbol can only match an identically named
STB_GLOBAL definition which refers to one of these version definitions via an index with bit 15 clear.
Each top-level version definition links via its vd_aux field to a list of version names. Each link contains the byte
offset between the start of the structure containing it and the start of the structure linked to. Zero marks the end of
the list. The first member of the list names the latest version, hashed in the version definition’s vd_hash field.
Subsequent members name predecessor versions, but these are irrelevant to both static and dynamic linking.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 11 of 45
ELF for the ARM Architecture
The symbol version section is a table of ELF32_Half values. The Nth entry in the section corresponds to the Nth
symbol in the dynamic symbol table.
0 if the symbol is local to this executable file.
1 if the symbol is undefined and unbound (to be bound dynamically), or if the symbol is defined and names
the version of the executable file (usually a shared object) itself.
The index (> 1) of the corresponding version definition, or version needed, in the virtual table of versions
(described in §3.1.1.1).
This is the same value as is stored in the vd_ndx field of a version definition structure and the vna_other
field of a version needed auxiliary structure.
Bit 15 of the index is set to denote that this is an old version of the symbol. Such symbols are not used during
static binding, but may be linked to during dynamic linking.
The versions needed section contains a list of needed DSOs, and the symbol versions needed from them.
Within each version needed structure, the vn_file field is the offset in the associated string section of the
SONAME of the needed DSO, and the vn_next field contains the byte offset from the start of this version needed
structure to the start of its successor.
Each version needed structure links to a sub-list of needed versions via a byte offset to the start of the first
member in its vn_aux field. In effect this represents FROM DSO IMPORT Ver1, Ver2, …
Each version needed auxiliary structure contains its index in the virtual table of versions in its vna_other field.
The vna_name field contains the offset in the associated string table of the name of the required version.
In the section view, the pre-emption map special section is called .ARM.preemptmap. It has type
SHT_ARM_PREEMPTMAP. In common with other sections that refer to a string table, its sh_link field contains the
section index of an associated string table.
The map contains a sequence of entries of the form:
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 12 of 45
ELF for the ARM Architecture
Symbol-name is the offset in the associated string table section of a NUL-terminated byte string (NTBS) that
names a symbol defined in a dynamic symbol table. This value must not be 0.
Each of pre-empting-DLL and pre-empted-DLL is an offset in the associated string table section of an NTBS
naming a DLL. The name used is the shared object name (SONAME) cited by DT_NEEDED dynamic tags. The root
executable file does not have a SONAME, so its name is encoded as 0.
Note There is no merit in making the final step PC-relative. A location must be written at dynamic link time and at
that time the target address must be known [even if dynamic linking is performed off line]. Similarly, it is
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 13 of 45
ELF for the ARM Architecture
generally pointless trying to construct a PLT entry entirely in 16-bit Thumb instructions. Even with the
overhead of an inline Thumb-to-ARM state change, an ARM-state entry is usually smaller and always
faster.
The table below summarizes the code generation variants a static linker must support. PLT refers to the read-only
component of the veneer and PLTGOT to the corresponding writable function pointer.
Platform family Neither ROM replaceable nor free of ROM replaceable, or PLT is free of
dynamic relocations dynamic relocations
DLL-like, single PLT code loads a function pointer from PLT code loads the PLTGOT entry SB-
address space the PLT, for example: relative (§A.1)
(Palm OS-like)
LDR pc, LX,
LX DCD R_ARM_GLOB_DAT(X)
DLL-like, multiple PLT code loads a function pointer from PLT code loads the PLTGOT entry via an
virtual address spaces the PLT (code and dynamic relocation address constant in the PLT (§A.2)
(Symbian OS-like) as shown above).
SVr4-like Not applicable, but as above if it were. PLT code loads the PLTGOT entry PC-
(Linux-like) relative (§A.3)
Following subsections present specimen ARM code sequences appropriate to the right hand column. In each
case simplification to the direct (no PLTGOT) case is shown in the left hand column.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 14 of 45
ELF for the ARM Architecture
4 OBJECT FILES
4.1 Introduction
To register a vendor prefix with ARM, please E-mail your request to arm.eabi at arm.com.
e_type
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 15 of 45
ELF for the ARM Architecture
There are currently no ARM-specific object file types. All values between ET_LOPROC and ET_HIPROC are
reserved to future revisions of this specification.
e_machine
An object file conforming to this specification must have the value EM_ARM (40, 0x28).
e_entry
The value stored in this field is treated like any other code pointer. Specifically, if bit[0] is 0b1 then the entry point
contains Thumb code; while bit[1:0] = 0b00 implies that the entry point contains ARM code. The combination
bit[1:0] = 0b10 is reserved.
The base ELF specification requires this field to be zero if an application does not have an entry point.
Nonetheless, some applications may require an entry point of zero (for example, via the reset vector).
A platform standard may specify that an executable file always has an entry point, in which case e_entry specifies
that entry point, even if zero.
e_flags
The processor-specific flags are shown in Table 4-2, ARM-specific e_flags. Unallocated bits, and bits allocated in
previous versions of this specification, are reserved to future revisions of this specification.
Value Meaning
EF_ARM_EABIMASK This masks an 8-bit version number, the version of the ABI to which this
(0xFF000000) ELF file conforms. This ABI is version 5. A value of 0 denotes unknown
(current version is 0x05000000) conformance.
EF_ARM_BE8 The ELF file contains BE-8 code, suitable for execution on an ARM
(0x00800000) Architecture v6 processor. This flag must only be set on an executable file.
EI_CLASS
EI_DATA
This field may be either ELFDATA2LSB or ELFDATA2MSB. The choice will be governed by the default data order
in the execution environment. On an Architecture v6 processor operating in BE8 mode all instructions are in little-
endian format. An executable image suitable for operation in this mode will have EF_ARM_BE8 set in the
e_flags field.
EI_OSABI
This field shall be zero unless the file uses objects that have flags which have OS-specific meanings (for example,
it makes use of a section index in the range SHN_LOOS through SHN_HIOS). There is currently one processor-
specific values for this field, defined in Table 4-3 ARM-specific EI_OSABI values.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 16 of 45
ELF for the ARM Architecture
Value Meaning
ELFOSABI_ARM_AEABI The object contains symbol versioning extensions as described in §3.1.1 Symbol
(64) Versioning.
4.4 Sections
SHT_ARM_EXIDX marks a section containing index information for exception unwinding. See EHABI for details.
SHT_ARM_PREEMPTMAP marks a section containing a BPABI DLL dynamic linking pre-emption map. See
§3.1.2.1, Pre-emption Map Format.
SHT_ARM_ATTRIBUTES marks a section containing object compatibility attributes. See §4.4.6 Build Attributes.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 17 of 45
ELF for the ARM Architecture
A relocation directive addresses a symbol within the section. The used object is the one addressed by the
symbol irrespective of the addend used.
Names beginning .ARM.exidx name sections containing index entries for section unwinding. Names beginning
.ARM.extab name sections containing exception unwinding information. See [EHABI] for details.
.ARM.preemptmap names a section that contains a BPABI DLL dynamic linking pre-emption map. See §3.1.2.1,
Pre-emption Map Format.
.ARM.attributes names a section that contains build attributes. See §4.4.6 Build Attributes.
.ARM.debug_overlay and .ARM.overlay_table name sections used by the Debugging Overlaid Programs
ABI extension described in [DBGOVL].
Additional special sections may be required by some platforms standards.
The content of the section is a stream of bytes. Numbers other than subsection sizes are encoded numbers using
unsigned LEB128 encoding (ULEB128), DWARF-3 style [GDWARF].
Attributes are divided into sub-sections. Each subsection is prefixed by the name of the vendor. There is one
subsection that is defined by the “aeabi” pseudo-vendor and contains general information about compatibility of
the object file. Attributes defined in vendor-specific sections are private to the vendor. In a conforming object file
the information recorded in a vendor-specific section may be safely ignored if it is not understood.
Most build attributes naturally apply to a whole translation unit; however, others might apply more naturally to a
section or to a function (symbol of type STT_FUNC). To permit precise description of attributes the syntax permits
three granularities of translation at which an attribute can be expressed.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 18 of 45
ELF for the ARM Architecture
A section inherits the attributes of the file of which it is a component. A symbol definition inherits the attributes of
the section in which it is defined. Attributes that cannot apply to the smaller entity are not inherited.
Note Attributes that naturally apply to a translation unit may, nonetheless, end up applying to a section if
sections from distinct relocatable files are combined into a single relocatable file by "partial linking". Similar
exceptions may occur at the function level through use of #pragma and other Q-o-I tool chain behavior.
Explicit per-section and per-symbol data should be generated only when it cannot be implied by this
inheritance. Being explicit is more verbose, and the explicit options are intended to capture exceptions.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 19 of 45
ELF for the ARM Architecture
A set of (defined) symbols in the relocatable file. These sub-subsections contain a list of symbol numbers
followed by a list of attributes.
A sub-subsection starts with a tag that identifies the type of the sub-subsection (file, section, or symbol), followed
by a 4-byte unsigned integer size in the byte-order of the ELF file. The size is the total size of the sub-subsection
including the tag, the size itself, and the sub-subsection content.
Both section indexes and defined symbol indexes are non-zero, so a NUL byte ends a string and a list of indexes.
There are no constraints on the order or number of sub-subsections in a vendor subsection. A consumer that
needs the data in inheritance order can obtain the file attributes, the section-related attributes, and the symbol-
related attributes, by making three passes over the subsection.
A public attribute is encoded as a tag (non zero, ULEB128-encoded followed by a value. A public value is either
an enumeration constant (ULEB128-encoded) or a NUL-terminated string.
Some examples of tags and their argument sorts include:
Tag_CPU_raw_name <string> -- 0x04, "ML692000"
Tag_CPU_name <string> -- 0x05, "ARM946E-S"
Tag_PCS_R9_use <uleb128> -- 0x0E, 0x01 (R9 used as SB)
Tag_PCS_config <uleb128> -- 0x0D, 0x03 (Linux DSO [/fpic] configuration)
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 20 of 45
ELF for the ARM Architecture
All extern data objects shall have type STT_OBJECT. No STB_GLOBAL data symbol shall have type STT_FUNC.
The type of an undefined symbol shall be STT_NOTYPE or the type of its expected definition.
The type of any other symbol defined in an executable section can be STT_NOTYPE. The linker is only required to
provide interworking support for symbols of type STT_FUNC (interworking for untyped symbols must be encoded
directly in the object file).
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 21 of 45
ELF for the ARM Architecture
If the symbol labels an object in a section with the SHF_MERGE flag set, the relocation using symbol may be
changed to use the section symbol only if the initial addend of the relocation is zero.
No tool is required to perform the above transformations; an object consumer must be prepared to do this itself if it
might find the additional symbols confusing.
Note Multiple conventions exist for the names of compiler temporary symbols (for example, ARMCC uses
Lxxx.yyy, while GNU uses .Lxxx).
The mapping symbols are defined in Table 4-6, Mapping symbols. It is an error for a relocation to reference a
mapping symbol. Two forms of mapping symbol are supported:
a short form, that uses a dollar character and a single letter denoting the class. This form can be used when
an object producer creates mapping symbols automatically, and minimizes symbol table space
a longer form, where the short form is extended with a period and then any sequence of characters that are
legal for a symbol. This form can be used when assembler files have to be annotated manually and the
assembler does not support multiple definitions of symbols.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 22 of 45
ELF for the ARM Architecture
Name Meaning
$a Start of a sequence of ARM instructions
$a.<any…>
$d Start of a sequence of data items (for example, a literal pool)
$d.<any…>
$t Start of a sequence of Thumb instructions
$t.<any…>
4.7 Relocation
Relocation information is used by linkers in order to bind symbols and addresses that could not be determined
when the initial object was generated.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 23 of 45
ELF for the ARM Architecture
Some examples are shown in Table 4-7, Examples of REL format initial addends.
If the initial addend cannot be encoded in the space available then a RELA format relocation must be used.
There are three special cases for forming the initial addend of REL-type relocations where the immediate field
cannot normally hold small signed integers:
For relocations processing MOVW and MOVT instructions (in both ARM and Thumb state), the initial addend is
formed by sign-extending the 16-bit constant to 32 bits. In the case of MOVT this implies that the natural
interpretation of the immediate field is shifted right by 16 bits before the sign extension.
For R_ARM_THM_JUMP6 the initial addend is formed by the formula (((imm + 4) & 0x7f) – 4), where
imm is the contatenation of bit[9]:bit[7:3]:’0’ from the Thumb CBZ or CBNZ instruction being
relocated.
For R_ARM_THM_PC8 the initial addend is formed by the formula (((imm + 4) & 0x3ff) – 4), where
imm is the normal interpretation of the immediate field in a Thumb LDR(3)/LDR(lliteral) instruction.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 24 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 25 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 26 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 27 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 28 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 29 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 30 of 45
ELF for the ARM Architecture
There is one relocation (R_ARM_CALL) for unconditional function call instructions (BLX and BL with the condition
field set to 0xe), and one for jump instructions (R_ARM_JUMP24). The principal difference between the two
relocation values is the handling of ARM/Thumb inter-working: on ARM architecture 5 and above, an instruction
relocated by R_ARM_CALL that calls a function that is entered in Thumb state may be relocated by changing the
instruction to BLX; an instruction relocated by R_ARM_JUMP24 must use a veneer to effect the transition to Thumb
state. Conditional function call instructions (BL<cond>) must be relocated using R_ARM_JUMP24.
A linker may use a veneer (a sequence of instructions) to implement the relocated branch if the relocation is one
of R_ARM_PC24, R_ARM_CALL, R_ARM_JUMP24, R_ARM_THM_CALL, (or, in Thumb state, R_ARM_THM_JUMP24,
or R_ARM_THM_JUMP19) and:
The target symbol has type STT_FUNC
Or, the target symbol and relocated place are in separate sections input to the linker
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 31 of 45
ELF for the ARM Architecture
In all other cases a linker shall diagnose an error if relocation cannot be effected without a veneer. A linker
generated veneer may corrupt register r12 (IP) and the condition flags, but must preserve all other registers. On
M-profile processors a veneer may also assume the presence of a stack with at least 8 bytes (2 words) of
memory. Linker veneers may be needed for a number of reasons, including, but not limited to:
Target is outside the addressable span of the branch instruction (+/- 32Mb)
Target address and execution state will not be known until run time, or the address might be pre-empted
In some systems indirect calls may also use veneers in order to support dynamic linkage while preserving pointer
equivalence.
On platforms that do not support dynamic pre-emption of symbols an unresolved weak reference to a symbol
relocated by R_ARM_CALL shall be treated as a jump to the next instruction (the call becomes a no-op). The
behaviour of R_ARM_JUMP24 in these conditions is unspecified.
Group relocations
Relocation codes 4 and 57-83 are intended to relocate sequences of instructions that generate a single address.
They are encoded to extract the maximum flexibility from the ARM ADD- and SUB-immediate instructions without
need to determine during linking the full sequence being used. The relocations operate by performing the basic
relocation calculation and then partitioning the result into a set of groups of bits that can be statically determined.
All processing for the formation of the groups is done on the absolute value of X; the sign of X is used to
determine whether ADD or SUB instructions are used, or, if the sequence concludes with a load/store operation,
the setting of the U bit (bit 23) in the instruction.
A group, Gn, is formed by examining the residual value, Yn, after the bits for group Gn–1 have been masked off.
Processing for group G0 starts with the absolute value of X. For ALU-type relocations a group is formed by
determining the most significant bit (MSB) in the residual and selecting the smallest constant Kn such that
Yn & ~Gn.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 32 of 45
ELF for the ARM Architecture
documented here for completeness. A linker is not required to generate trampoline sequences (or veneers) to
extend the branching range of the jump relocations.
Relocation R_ARM_THM_JUMP6 is only applicable to the Thumb-2 instruction set.
(In the following table, references in the style LDR(1) refer to the ARMv5 Architecture Reference Manual [ARMv5
ARM] while those in the style LDR(immediate, Thumb) give the corresponding reference to the ARM Architecture
Reference Manual ARM v7-A and ARM v7-R edition [ARM ARM]).
R_ARM_THM_CALL is used to relocate Thumb BL (and ARMv5 Thumb BLX) instructions. It is the Thumb
equivalent of R_ARM_CALL and the same rules on conversion apply. Bits 0-10 of the first half-word encode the
most significant bits of the branch offset, bits 0-10 of the second half-word encode the least significant bits and the
offset is in units of half-words. Thus 22 bits encode a branch offset of +/- 222 bytes. When linking ARMv6 (and
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 33 of 45
ELF for the ARM Architecture
later) Thumb code the range of the branch is increased by 2 bits, increasing the offset range to +/- 224 bytes. The
same relocation is used for both cases since a linker need only know that the code will run on a Thumb-2 (ARMv6
and later) capable processor to exploit the additional range.
The conditions under which and are permitted to generate an ip-corrupting intra-call veneer are specified in
§4.7.1.4 under the heading Call and Jump relocations.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 34 of 45
ELF for the ARM Architecture
Other execution environments may require that the GOT origin be congruent with some other base. In these
environments the appropriate means of establishing that base will apply.
In addition to the data generating relocations listed above the call and branch relocations (R_ARM_CALL,
R_ARM_THM_CALL, R_ARM_JUMP24, R_ARM_THM_JUMP24, R_ARM_THM_JUMP19) may also require a proxy to be
generated if the symbol will be defined in an external executable or may be pre-empted at execution time. The
details of proxy sequences and locations are described in §3.1.3, PLT Sequences and Usage Models.
R_ARM_GOTRELAX is reserved to permit future-linker based optimizations of GOT addressing sequences.
R_ARM_TLS_LDM32 is the same as R_ARM_TLS_GD32 except that the second slot in the GOT is initialized to zero
and has no dynamic relocation.
R_ARM_TLS_LDO32 resolves to the offset of the referenced data object (which must be local to the module) from
the origin of the TLS block for the current module.
R_ARM_TLS_LDO12 is the same as R_ARM_TLS_LDO32 except that the result of the relocation is encoded as the
12-bit offset of an ARM LDR instruction.
R_ARM_TLS_LE32 resolves to the offset of the referenced data object (which must be in the initial data block)
from the thread pointer ($tp).
R_ARM_TLS_LE12 is the same as R_ARM_TLS_LE32 except that the result of the relocation is encoded as the
12-bit offset of an ARM LDR instruction.
R_ARM_TLS_IE32 allocates an entry in the GOT that is dynamically relocated by R_ARM_TLS_TPOFF32. The
place resolves to the offset of the GOT entry from the place.
R_ARM_TLS_IE12GP allocates an entry in the GOT that is dynamically relocated by R_ARM_TLS_TPOFF32. The
place resolved to the offset of the GOT entry from the origin of the GOT and is encoded in the 12-bit offset of an
ARM LDR instruction.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 35 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 36 of 45
ELF for the ARM Architecture
hold the full copy of the symbol. If the object being copied contains dynamic relocations then the effect must be
as if those relocations were performed before the copy was made.
Note R_ARM_COPY is normally only used in SVr4 type environments where the executable is not position
independent and references by the code and read-only data sections cannot be relocated dynamically to
refer to an object that is defined in a shared library.
The need for copy relocations can be avoided if a compiler generates all code references to such objects
indirectly through a dynamically relocatable location, and if all static data references are placed in
relocatable regions of the image. In practice, however, this is difficult to achieve without source-code
annotation; a better approach is to avoid defining static global data in shared libraries.
Relocation Replacement
R_ARM_PC24 Use R_ARM_CALL or R_ARM_JUMP24
R_ARM_PLT32 Use R_ARM_CALL or R_ARM_JUMP24
R_ARM_LDR_SBREL_11_0_NC Use R_ARM_LDR_SB_Gxxx
R_ARM_ALU_SBREL_19_12_NC Use R_ARM_ALU_SB_Gxxx
R_ARM_ALU_SBREL_27_20_CK Use R_ARM_ALU_SB_Gxxx
R_ARM_SBREL31 Use new exception table format. Previous drafts of this document sometimes
referred to this relocation as R_ARM_ROSEGREL32.
R_ARM_GNU_VTENTRY None
R_ARM_GNU_VTINHERIT None
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 37 of 45
ELF for the ARM Architecture
4.7.2 Idempotency
All RELA type relocations are idempotent. They may be reapplied to the place and the result will be the same.
This allows a static linker to preserve full relocation information for an image by converting all REL type relocations
into RELA type relocations.
Note A REL type relocation can never be idempotent because the act of applying the relocation destroys the
original addend.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 38 of 45
ELF for the ARM Architecture
5.1 Introduction
This section provides details of ARM-specific definitions and changes relating to executable images.
p_type
Table 5-1, Processor-specific segment types lists the processor-specific segment types.
A segment of type PT_ARM_ARCHEXT contains information describing the platform capabilities required by the
executable file. The segment is optional, but if present it must appear before segment of type PT_LOAD. The
platform independent parts of this segment are described in §5.2.1, Platform architecture compatibility .
PT_ARM_EXIDX (alias PT_ARM_UNWIND) describes the location of a program’s unwind tables.
p_flags
There are no processor-specific flags. All bits in the PT_MASKPROC part of this field are reserved to future
revisions of this specification.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 39 of 45
ELF for the ARM Architecture
Table 5-3, Architecture compatibility data formats lists the architecture compatibility data formats defined by this
ABI. All other format identifiers are reserved to future revisions of this specification.
Table 5-4, Architecture profile compatibility data, lists the values specifying the architectural profile needed by an
executable file.
PT_ARM_ARCHEXT_PROF_CLASSIC 0x00530000 The executable file requires the ‘classic’ (‘A’ or ‘R’ profile)
(‘S’<<16) exception model.
Table 5-5, Architecture version compatibility data defines the values that specify the minimum architecture version
needed by this executable file. These values are identical to those of the Tag_CPU_arch attribute used in the
attributes section [ABI-addenda, §2] of a relocatable file.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 40 of 45
ELF for the ARM Architecture
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 41 of 45
ELF for the ARM Architecture
DT_ARM_SYMTABSZ gives the number of entries in the dynamic symbol table, including the initial dummy symbol.
DT_ARM_PREEMPTMAP holds the address of the pre-emption map for platforms that use the DLL static binding
model. See §3.1.2 Symbol Pre-emption in DLLs for details. On platforms that permit use of a pre-emption map,
the DT_SONAME tag must be present in all shared objects.
Note Some executable images may exist that use DT_ARM_RESERVED1 and DT_ARM_RESERVED2 instead of
DT_ARM_SYMTABSZ and DT_ARM_PREEMPTMAP respectively. These tags use the d_un field in a manner
incompatible with the Generic ELF requirements.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 42 of 45
ELF for the ARM Architecture
The final DCD is subject to relocation by a PLTGOT-generating relocation directive. This directive may be
processed by a target-specific linker or by a target-specific post-linker. After processing:
The place contains the 32-bit offset from the static base (sb) of the PLTGOT entry for X.
The PLTGOT entry for X is subject to an R_ARM_JUMP_SLOT(X) dynamic relocation.
A more complicated sequence that avoids one of the memory accesses is:
ADD ip, sb, #:SB_OFFSET_27_20:__PLTGOT(X) ; R_ARM_ALU_SB_G0_NC(__PLTGOT(X))
ADD ip, ip, #:SB_OFFSET_19_12:__PLTGOT(X) ; R_ARM_ALU_SB_G1_NC(__PLTGOT(X))
LDR pc, [ip, #:SB_OFFSET_11_0:__PLTGOT(X)]! ; R_ARM_LDR_SB_G2(__PLTGOT(X))
If the linker can place all PLTGOT entries within 1MB of SB, the sequence becomes:
ADD ip, sb, #:SB_OFFSET_19_12:__PLTGOT(X) ; R_ARM_ALU_SB_G0_NC(__PLTGOT(X))
LDR pc, [ip, #:SB_OFFSET_11_0:__PLTGOT(X)]! ; R_ARM_LDR_SB_G1(__PLTGOT(X))
The write-back on the final LDR ensures that ip contains the address of the PLTGOT entry. This is critical to
incremental dynamic linking.
Note that ip addresses the PLTGOT entry, which is critical to incremental dynamic linking.
The final DCD is subject to relocation by a PLTGOT-generating relocation directive. This directive may be
processed by a target-specific linker or by a target-specific post-linker. After processing:
The place contains the 32-bit address of the PLTGOT entry for X.
The PLTGOT entry for X is subject to an R_ARM_JUMP_SLOT(X) dynamic relocation.
Because a DLL has two segments that can be loaded independently, there is no more efficient address generating
sequence – analogous to the SB-relative sequence shown in above – that does not require complex instruction
field-relocating directives to be processed at dynamic link time.
This ABI requires dynamic relocations to relocate 32-bit fields, so there is no sequence analogous to that of the
preceding subsection.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 43 of 45
ELF for the ARM Architecture
The final DCD is subject to static relocation by a PLTGOT-generating relocation directive. This directive may be
processed by a target-specific linker or by a target-specific post-linker. After processing:
The place contains the 32-bit offset from L1+8 to the PLTGOT entry for X.
The PLTGOT entry for X is subject to an R_ARM_JUMP_SLOT(X) dynamic relocation.
A more complicated, pc-relative, sequence that avoids one of the memory accesses is shown below. Because an
SVr4 executable file is compact (usually < 228 bytes) and rigid (it has only one base address, whereas a DLL has
two), all the relocations can be fully resolved during static linking.
ADD ip, pc, #-8:PC_OFFSET_27_20: __PLTGOT(X) ; R_ARM_ALU_PC_G0_NC(__PLTGOT(X))
ADD ip, ip, #-4:PC_OFFSET_19_12: __PLTGOT(X) ; R_ARM_ALU_PC_G1_NC(__PLTGOT(X))
LDR pc, [ip, #0:PC_OFFSET_11_0: __PLTGOT(X)]! ; R_ARM_LDR_PC_G2(__PLTGOT(X))
The write-back on the final LDR ensures that ip contains the address of the PLTGOT entry. This is critical to
incremental dynamic linking.
In effect, the sequence constructs a 28-bit offset for the LDR. The first relocation does the right thing because pc
addresses the LDR, so, in general, it picks out bits [27-20] of that offset. The third relocation picks out bits [11-0] of
the same offset. The second relocation needs to construct bits [19-12] of the offset from dot+4 to X., that is, from
dot to X-4. Ignoring the -4 sometimes produces the wrong answer!
Encoding such a small addend requires that the initial value not be shifted by the shift applied to the result value.
This is expected for a RELA-type relocation that can encode -4 directly. However, a REL-type must encode the
initial value of the addend using SUB ip, ip, #4.
In small enough DSOs (< 220 bytes from the PLT to the PLTGOT) the first instruction can be omitted, and the
sequence collapses to the following.
SUB ip, pc, #4:PC_OFFSET_19_12: __PLTGOT(X) ; R_ARM_ALU_PC_G0_NC(__PLTGOT(X))
LDR pc, [ip, #0:PC_OFFSET_11_0: __PLTGOT(X)]! ; R_ARM_LDR_PC_G2(__PLTGOT(X))
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 44 of 45
ELF for the ARM Architecture
A toolchain may define these symbols unconditionally, or only if they are referred to by the application: so a post-
linker must not depend on the existence of any of these symbols.
where AA, AT, TA, or TT denotes the type of the veneer — ARM to ARM, ARM to Thumb, etc; I, L, or S denotes
inline (the target follows immediately), long reach (32-bit), or short reach (typically 26-bit); and $PI denotes that
the veneer is position independent.
ARM IHI 0044D Copyright © 2003-2009 ARM Limited. All rights reserved. Page 45 of 45