
- •ABOUT THIS DOCUMENT
- •Change control
- •Current status and anticipated changes
- •Change history
- •References
- •Terms and abbreviations
- •SCOPE
- •GENERIC 32-BIT ELF
- •Introduction
- •File Format
- •Data Representation
- •Character Representations
- •ELF Header
- •ELF Identification
- •Sections
- •Special Sections
- •String Table
- •Symbol Table
- •Symbol Values
- •Relocation
- •Program view
- •Program Header
- •Note Section
- •Program Loading
- •Dynamic Linking
- •Special Sections Names
- •Pre-existing Extensions
- •ELF header
- •Entry points
- •Section names
- •Section headers
- •Common sections
- •Section alignment
- •Link and info fields
- •Symbols
- •Symbol value
- •Symbol size
- •Weak symbols
- •Symbol names
- •Sub-class and super-class symbols
- •Function address constants and pointers to code
- •Mapping and tagging symbols
- •Mapping symbols
- •Tagging symbols
- •Symbol table order
- •Dynamic symbol table entries
- •Relocation types
- •Dynamic relocation types
- •Multiple relocation
- •Field extraction and insertion
- •Relocations that depend on the type of the target location
- •Program headers
- •Dynamic linking and relocation
- •The dynamic segment
- •The dynamic segment program header
- •The dynamic section
- •DT_SYMBOLIC
- •The hash table section
ARM ELF
4.7 Dynamic linking and relocation
A dynamically linked executable or shared object undergoes its final stage of linking when it is:
Loaded into memory by a program loader.
Prepared for ROM by a ROM builder.
An executable or shared object to be linked dynamically may:
List one or more shared objects (shared libraries) with which it should be linked.
Refer to symbols defined by these shared objects, the execution environment, or the ROM builder. These references appear as undefined symbols in the dynamic symbol table.
Define symbols that can be referred to by these shared objects, the execution environment, or the ROM builder. These symbols are defined in the dynamic symbol table.
List locations to be relocated whose values depend on:
-The actual execution addresses given to program segments.
-The values of symbols defined during dynamic linking.
In general, some storage units will need to be relocated when symbolic references are resolved.
4.7.1 The dynamic segment
If an ARM executable or shared object needs dynamic linking, or is re-locatable, it contains a program segment of type PT_DYNAMIC. The dynamic segment contains:
A dynamic section (see 4.7.3, The dynamic section) that describes the dynamic segment.
A string table used by the symbol table and directly by some dynamic section entries (see 3.4, String Table).
A dynamic symbol table section. This has the same format as a symbol table (see 3.5, Symbol Table), but may use a different interpretation of st_shndx (see 4.4.9, Dynamic symbol table entries).
A section containing relocations (a section of sort SHT_REL and/or SHT_RELA). This has the same format as any other relocation section (see 3.6, Relocation).
A hash table that accelerates use of the symbol table (see 4.7.4, The hash table section).
Optionally, section headers of the following types may describe these sub-sections of the dynamic segment:
SHT_DYNAMIC—the dynamic array itself.
SHT_STRTAB—the string table.
SHT_DYNSYM—the symbol table.
SHT_REL and/or SHT_RELA—the relocation section(s).
SHT_HASH—the symbol hash table.
Dynamic linkers do not use this section view.
4.7.2 The dynamic segment program header
The dynamic segment program header has p_type = PT_DYNAMIC (= 2).
The ARM EABI defines no meaning for the following fields of the program header of a dynamic segment:
p_vaddr, p_paddr, p_memsz, p_align.
The PF_MASKPROC sub-field of p_flags.
Operating environments are free to define their own semantics for these fields.
SWS ESPC 0003 B-02 |
Page 40 of 42 |