R_SPARC_GOT10

Resembles R_SPARC_LO10, except that it refers to the address of the symbol's global offset table entry. Additionally, R_SPARC_GOT10 instructs the link-editor to create a global offset table.

R_SPARC_GOT13

Resembles R_SPARC_13, except that it refers to the address of the symbol's global offset table entry. Additionally, R_SPARC_GOT13 instructs the link-editor to create a global offset table.

R_SPARC_GOT22

Resembles R_SPARC_22, except that it refers to the address of the symbol's global offset table entry. Additionally, R_SPARC_GOT22 instructs the link-editor to create a global offset table.

R_SPARC_WPLT30

Resembles R_SPARC_WDISP30, except that it refers to the address of the symbol's procedure linkage table entry. Additionally, R_SPARC_WPLT30 instructs the link-editor to create a procedure linkage table.

R_SPARC_COPY

Created by the link-editor for dynamic executables to preserve a read-only text segment. Its offset member refers to a location in a writable segment. The symbol table index specifies a symbol that should exist both in the current object file and in a shared object. During execution, the runtime linker copies data associated with the shared object's symbol to the location specified by the offset. See "Copy Relocations".

R_SPARC_GLOB_DAT

Resembles R_SPARC_32, except that it sets a global offset table entry to the address of the specified symbol. The special relocation type enables you to determine the correspondence between symbols and global offset table entries.

R_SPARC_JMP_SLOT

Created by the link-editor for dynamic objects to provide lazy binding. Its offset member gives the location of a procedure linkage table entry. The runtime linker modifies the procedure linkage table entry to transfer control to the designated symbol address.

R_SPARC_RELATIVE

Created by the link-editor for dynamic objects. Its offset member gives the location within a shared object that contains a value representing a relative address. The runtime linker computes the corresponding virtual address by adding the virtual address at which the shared object is loaded to the relative address. Relocation entries for this type must specify 0 for the symbol table index.

R_SPARC_UA32

Resembles R_SPARC_32, except that it refers to an unaligned word. The word to be relocated must be treated as four separate bytes with arbitrary alignment, not as a word aligned according to the architecture requirements.

R_SPARC_OLO10

Resembles R_SPARC_LO10, except that an extra offset is added to make full use of the 13-bit signed immediate field.

R_SPARC_LM22

Resembles R_SPARC_HI22, except that it truncates rather than validates.

R_SPARC_PC_LM22

Resembles R_SPARC_PC22, except that it truncates rather than validates.

R_SPARC_HIX22

Used with R_SPARC_LOX10 for executables that will be confined to the uppermost 4 gigabytes of the 64-bit address space. Similar to R_SPARC_HI22, but supplies ones complement of linked value.

R_SPARC_LOX10

Used with R_SPARC_HIX22. Similar to R_SPARC_LO10, but always sets bits 10 through 12 of the linked value.

R_SPARC_L44

Used with the R_SPARC_H44 and R_SPARC_M44 relocation types to generate a 44-bit absolute addressing model.

R_SPARC_REGISTER

Used to initialize a register symbol. Its offset member contains the register number to be initialized. There must be a corresponding register symbol for this register of type SHN_ABS.

64-bit SPARC: Relocation Types

The relocations listed in the following table extend, or alter, those define for 32-bit SPARC. See "SPARC: Relocation Types".

Table 7-28 64-bit SPARC: ELF Relocation Types

IA: Relocation Types

The relocations listed in the following table are defined for 32-bit IA.

Table 7-29 IA: ELF Relocation Types

Some relocation types have semantics beyond simple calculation:

R_386_GOT32

Computes the distance from the base of the global offset table to the symbol's global offset table entry. It also instructs the link-editor to create a global offset table.

R_386_PLT32

Computes the address of the symbol's procedure linkage table entry and instructs the link-editor to create a procedure linkage table.

R_386_COPY

Created by the link-editor for dynamic executables to preserve a read-only text segment. Its offset member refers to a location in a writable segment. The symbol table index specifies a symbol that should exist both in the current object file and in a shared object. During execution, the runtime linker copies data associated with the shared object's symbol to the location specified by the offset. See "Copy Relocations".

R_386_GLOB_DAT

Used to set a global offset table entry to the address of the specified symbol. The special relocation type enable you to determine the correspondence between symbols and global offset table entries.

R_386_JMP_SLOT

Created by the link-editor for dynamic objects to provide lazy binding. Its offset member gives the location of a procedure linkage table entry. The runtime linker modifies the procedure linkage table entry to transfer control to the designated symbol address.

R_386_RELATIVE

Created by the link-editor for dynamic objects. Its offset member gives the location within a shared object that contains a value representing a relative address. The runtime linker computes the corresponding virtual address by adding the virtual address at which the shared object is loaded to the relative address. Relocation entries for this type must specify 0 for the symbol table index.

R_386_GOTOFF

Computes the difference between a symbol's value and the address of the global offset table. It also instructs the link-editor to create the global offset table.

R_386_GOTPC

Resembles R_386_PC32, except that it uses the address of the global offset table in its calculation. The symbol referenced in this relocation normally is _GLOBAL_OFFSET_TABLE_, which also instructs the link-editor to create the global offset table.

Comdat Section

Comdat sections uniquely identified by their section name (sh_name). If the link-editor encounters multiple sections of type SHT_SUNW_COMDAT with the same section name, the first one will be retained and all others will be discarded. Any relocations applied to a discarded SHT_SUNW_COMDAT section will be ignored and any symbols defined in a discarded section will not be kept.

Additionally the link-editor also supports the section naming convention used for section reordering when the compiler is invoked with the -xF option. If the sections are placed in a section of the name .funcname%sectname the final SHT_SUNW_COMDAT sections that have been retained will be coalesced into a section identified by the .sectname. Using this method, the SHT_SUNW_COMDAT sections can be placed into the .text, .data, or any other section as their final destination.

Versioning Information

Objects created by the link-editor can contain two types of versioning information:

• Version definitions provide associations of global symbols and are implemented using sections of type SHT_SUNW_verdef and SHT_SUNW_versym.

• Version dependencies indicate the version definition requirements from other object dependencies and are implemented using sections of type SHT_SUNW_verneed.

The structures that form these sections are defined in sys/link.h. Sections that contain versioning information are named .SUNW_version.

Version Definition Section

This section is defined by the type SHT_SUNW_verdef. If this section exists, a SHT_SUNW_versym section must also exist. Using these two structures, an association of symbols-to-version definitions is maintained within the file. See "Creating a Version Definition". Elements of this section have the following structure:

typedef struct {
        Elf32_Half      vd_version;
        Elf32_Half      vd_flags;
        Elf32_Half      vd_ndx;
        Elf32_Half      vd_cnt;
        Elf32_Word      vd_hash;
        Elf32_Word      vd_aux;
        Elf32_Word      vd_next;
} Elf32_Verdef;
 
typedef struct {
        Elf32_Word      vda_name;
        Elf32_Word      vda_next;
} Elf32_Verdaux;

typedef struct {
        Elf64_Half      vd_version;
        Elf64_Half      vd_flags;
        Elf64_Half      vd_ndx;
        Elf64_Half      vd_cnt;
        Elf64_Word      vd_hash;
        Elf64_Word      vd_aux;
        Elf64_Word      vd_next;
} Elf64_Verdef;
 
typedef struct {
        Elf64_Word      vda_name;
        Elf64_Word      vda_next;
} Elf64_Verdaux;