- r_offset
This member gives the location at which to apply the relocation action. Different object files have slightly different interpretations for this member.
For a relocatable file, the value indicates a section offset. The relocation section itself describes how to modify another section in the file. Relocation offsets designate a storage unit within the second section.
For an executable or shared object, the value indicates the virtual address of the storage unit affected by the relocation. This information makes the relocation entries more useful for the runtime linker.
Although the interpretation of the member changes for different object files to allow efficient access by the relevant programs, the meanings of the relocation types stay the same.
- r_info
This member gives both the symbol table index, with respect to which the relocation must be made, and the type of relocation to apply. For example, a call instruction's relocation entry will hold the symbol table index of the function being called. If the index is STN_UNDEF, the undefined symbol index, the relocation uses 0 as the symbol value.
Relocation types are processor-specific. A relocation entry's relocation type or symbol table index is the result of applying ELF32_R_TYPE or ELF32_R_SYM, respectively, to the entry's r_info member:
#define ELF32_R_SYM(info) ((info)>>8) #define ELF32_R_TYPE(info) ((unsigned char)(info)) #define ELF32_R_INFO(sym, type) (((sym)<<8)+(unsigned char)(type)) #define ELF64_R_SYM(info) ((info)>>32) #define ELF64_R_TYPE(info) ((Elf64_Word)(info)) #define ELF64_R_INFO(sym, type) (((Elf64_Xword)(sym)<<32)+ \ (Elf64_Xword)(type))
For Elf64_Rel and Elf64_Rela structures, the r_info field is further broken down into an 8-bit type identifier and a 24-bit type dependent data field:
#define ELF64_R_TYPE_DATA(info) (((Elf64_Xword)(info)<<32)>>40) #define ELF64_R_TYPE_ID(info) (((Elf64_Xword)(info)<<56)>>56) #define ELF64_R_TYPE_INFO(data, type) (((Elf64_Xword)(data)<<8)+ \ (Elf64_Xword)(type))
- r_addend
This member specifies a constant addend used to compute the value to be stored into the relocatable field.
Rela entries contain an explicit addend. Entries of type Rel store an implicit addend in the location to be modified. 32-bit and 64-bit SPARC use only Elf32_Rela and Elf64_Rela relocation entries respectively. Thus, the r_addend member serves as the relocation addend. IA uses only Elf32_Rel relocation entries. The field to be relocated holds the addend. In all cases, the addend and the computed result use the same byte order.
A relocation section can reference two other sections: a symbol table, identified by the sh_info section header entry, and a section to modify, identified by the sh_link section header entry. "Sections" specifies these relationships. An sh_link entry is required when a relocation section exists in a relocatable object, but is optional for executables and shared objects. The relocation offset is sufficient to perform the relocation.
Relocation Types (Processor-Specific)
Relocation entries describe how to alter instruction and data fields in the following figures. Bit numbers appear in the lower box corners.
On the SPARC platform, relocation entries apply to bytes (byte8), half-words (half16), or words (the others).
On 64-bit SPARC, relocations also apply to extended-words (xword64):
On IA, relocation entries apply to words (word32):
word32 specifies a 32-bit field occupying 4 bytes with an arbitrary byte alignment. These values use the same byte order as other word values in the IA architecture:
In all cases, the r_offset value designates the offset or virtual address of the first byte of the affected storage unit. The relocation type specifies which bits to change and how to calculate their values.
Calculations for the following relocation types assume the actions are transforming a relocatable file into either an executable or a shared object file. Conceptually, the link-editor merges one or more relocatable files to form the output. The link-editor first decides how to combine and locate the input files. Then it updates the symbol values. Finally the link-editor performs the relocation. Relocations applied to executable or shared object files are similar and accomplish the same result. Descriptions in the tables in this section use the following notation:
A | The addend used to compute the value of the relocatable field. |
B | The base address at which a shared object is loaded into memory during execution. Generally, a shared object file is built with a 0 base virtual address, but the execution address is different. See "Program Header". |
G | The offset into the global offset table at which the address of the relocation entry's symbol resides during execution. See "Global Offset Table (Processor-Specific)". |
GOT | The address of the global offset table. See "Global Offset Table (Processor-Specific)". |
L | The section offset or address of the procedure linkage table entry for a symbol. See "Procedure Linkage Table (Processor-Specific)". |
P | The section offset or address of the storage unit being relocated, computed using r_offset. |
S | The value of the symbol whose index resides in the relocation entry. |
SPARC: Relocation Types
Field names in the following table tell whether the relocation type checks for overflow. A calculated relocation value can be larger than the intended field, and a relocation type can verify (V) the value fits or truncate (T) the result. As an example, V-simm13 means that the computed value can not have significant, nonzero bits outside the simm13 field.
Table 7-27 SPARC: ELF Relocation Types
Name | Value | Field | Calculation |
---|---|---|---|
R_SPARC_NONE | 0 | None | None |
R_SPARC_8 | 1 | V-byte8 | S + A |
R_SPARC_16 | 2 | V-half16 | S + A |
R_SPARC_32 | 3 | V-word32 | S + A |
R_SPARC_DISP8 | 4 | V-byte8 | S + A - P |
R_SPARC_DISP16 | 5 | V-half16 | S + A - P |
R_SPARC_DISP32 | 6 | V-disp32 | S + A - P |
R_SPARC_WDISP30 | 7 | V-disp30 | (S + A - P) >> 2 |
R_SPARC_WDISP22 | 8 | V-disp22 | (S + A - P) >> 2 |
R_SPARC_HI22 | 9 | T-imm22 | (S + A) >> 10 |
R_SPARC_22 | 10 | V-imm22 | S + A |
R_SPARC_13 | 11 | V-simm13 | S + A |
R_SPARC_LO10 | 12 | T-simm13 | (S + A) & 0x3ff |
R_SPARC_GOT10 | 13 | T-simm13 | G & 0x3ff |
R_SPARC_GOT13 | 14 | V-simm13 | G |
R_SPARC_GOT22 | 15 | T-simm22 | G >> 10 |
R_SPARC_PC10 | 16 | T-simm13 | (S + A - P) & 0x3ff |
R_SPARC_PC22 | 17 | V-disp22 | (S + A - P) >> 10 |
R_SPARC_WPLT30 | 18 | V-disp30 | (L + A - P) >> 2 |
R_SPARC_COPY | 19 | None | None |
R_SPARC_GLOB_DAT | 20 | V-word32 | S + A |
R_SPARC_JMP_SLOT | 21 | None | See R_SPARC_JMP_SLOT, |
R_SPARC_RELATIVE | 22 | V-word32 | B + A |
R_SPARC_UA32 | 23 | V-word32 | S + A |
R_SPARC_PLT32 | 24 | V-word32 | L + A |
R_SPARC_HIPLT22 | 25 | T-imm22 | (L + A) >> 10 |
R_SPARC_LOPLT10 | 26 | T-simm13 | (L + A) & 0x3ff |
R_SPARC_PCPLT32 | 27 | V-word32 | L + A - P |
R_SPARC_PCPLT22 | 28 | V-disp22 | (L + A - P) >> 10 |
R_SPARC_PCPLT10 | 29 | V-simm13 | (L + A - P) & 0x3ff |
R_SPARC_10 | 30 | V-simm10 | S + A |
R_SPARC_11 | 31 | V-simm11 | S + A |
R_SPARC_OLO10 | 33 | V-simm13 | ((S + A) & 0x3ff) + O |
R_SPARC_HH22 | 34 | V-imm22 | (S + A) >> 42 |
R_SPARC_HM10 | 35 | T-simm13 | ((S + A) >> 32) & 0x3ff |
R_SPARC_LM22 | 36 | T-imm22 | (S + A) >> 10 |
R_SPARC_PC_HH22 | 37 | V-imm22 | (S + A - P) >> 42 |
R_SPARC_PC_HM10 | 38 | T-simm13 | ((S + A - P) >> 32) & 0x3ff |
R_SPARC_PC_LM22 | 39 | T-imm22 | (S + A - P) >> 10 |
R_SPARC_WDISP16 | 40 | V-d2/disp14 | (S + A - P) >> 2 |
R_SPARC_WDISP19 | 41 | V-disp19 | (S + A - P) >> 2 |
R_SPARC_7 | 43 | V-imm7 | S + A |
R_SPARC_5 | 44 | V-imm5 | S + A |
R_SPARC_6 | 45 | V-imm6 | S + A |
R_SPARC_HIX22 | 48 | V-imm22 | ((S + A) ^ 0xffffffffffffffff) >> 10 |
R_SPARC_LOX10 | 49 | T-simm13 | ((S + A) & 0x3ff) | 0x1c00 |
R_SPARC_H44 | 50 | V-imm22 | (S + A) >> 22 |
R_SPARC_M44 | 51 | T-imm10 | ((S + A) >> 12) & 0x3ff |
R_SPARC_L44 | 52 | T-imm13 | (S + A) & 0xfff |
R_SPARC_REGISTER | 53 | V-word32 | S + A |
R_SPARC_UA16 | 55 | V-half16 | S + A |
Some relocation types have semantics beyond simple calculation: