Except for the DT_NULL element at the end of the dynamic array and the relative order of DT_NEEDED and DT_POSFLAG_1 elements, entries can appear in any order. Tag values not appearing in the table are reserved.

Table 7-43 ELF Dynamic Flags, DT_FLAGS

DF_ORIGIN

Indicates that the object requires $ORIGIN processing. See "Locating Associated Dependencies".

DF_SYMBOLIC

Indicates that the object contains symbolic bindings that were applied during its link-edit. See "Using -Bsymbolic".

DF_TEXTREL

Indicates that one or more relocation entries might request modifications to a non-writable segment, and the runtime linker can prepare accordingly. See "Position-Independent Code".

DF_BIND_NOW

Indicates that all relocations for this object must be processed before returning control to the program. The presence of this entry takes precedence over a directive to use lazy binding when specified through the environment or via dlopen(3DL). See "When Relocations Are Performed".

Table 7-44 ELF Dynamic Flags, DT_FLAGS_1

DF_1_NOW

Indicates that all relocations for this object must be processed before returning control to the program. The presence of this flag takes precedence over a directive to use lazy binding when specified through the environment or via dlopen(3DL). See "When Relocations Are Performed".

DF_1_GROUP

Indicates that the object is a member of a group. This flag is recorded in the object using the link-editor's -B group option. See "Object Hierarchies".

DF_1_NODELETE

Indicates that the object cannot be deleted from a process. If the object is loaded in a process, either directly or as a dependency, with dlopen(3DL), it cannot be unloaded with dlclose(3DL). This flag is recorded in the object using the link-editor's -z nodelete option.

DF_1_LOADFLTR

Meaningful only for filters. Indicates that all associated filtees be processed immediately. This flag is recorded in the object using the link-editor's -z loadfltr option. See "Filtee Processing".

DF_1_INITFIRST

Indicates that this object's initialization section be run before any other objects loaded with it.This flag is intended for specialized system libraries only, and is recorded in the object using the link-editor's -z initfirst option.

DF_1_NOOPEN

Indicates that the object cannot be added to a running process with dlopen(3DL). This flag is recorded in the object using the link-editor's -z nodlopen option.

DF_1_ORIGIN

Indicates that the object requires $ORIGIN processing. See "Locating Associated Dependencies".

DF_1_DIRECT

Indicates that the object should use direct binding information. See "Direct Binding".

DF_1_INTERPOSE

Indicates that the objects symbol table is to interpose before all symbols except the primary load object, which is typically the executable. This flag is recorded with the link-editor's -z interpose option. See "Direct Binding".

DF_1_NODEFLIB

Indicates that the search for dependencies of this object will ignore any default library search paths. This flag is recorded in the object using the link-editor's -z nodefaultlib option. See "Directories Searched by the Runtime Linker".

DF_1_NODUMP

Indicates that this object will not be dumped by dldump(3DL). Candidates for this option include objects with no relocations that might get included when generating alternative objects using crle(1). This flag is recorded in the object using the link-editor's -z nodump option.

DF_1_CONFALT

Identifies this object as a configuration alternative object generated by crle(1). This flag triggers the runtime linker to search for a configuration file $ORIGIN/ld.config.app-name.

DF_1_ENDFILTEE

Meaningful only for filtees. Terminates a filters search for any further filtees. This flag is recorded in the object using the link-editor's -z endfiltee option. See "Reducing Auxiliary Searches".

DF_1_DISPRELDNE

Indicates that this object has displacement relocations applied. The displacement relocation records no longer exist within the object as they were discarded once the relocation was applied. See "Displacement Relocations".

DF_1_DISPRELPND

Indicates that this object has displacement relocations pending. The displacement relocations exits within the object so they can be completed at runtime. See "Displacement Relocations".

Table 7-45 ELF Dynamic Position Flags, DT_POSFLAG_1

DF_P1_LAZYLOAD

Identifies the following DT_NEEDED entry as an object to be lazy loaded. This flag is recorded in the object using the link-editor's -z lazyload option. See "Lazy Loading of Dynamic Dependencies".

DF_P1_GROUPPERM

Identifies the following DT_NEEDED entry as an object to be loaded as a group. This flag is recorded in the object using the link-editor's -z groupperm option. See "Isolating a Group".

Table 7-46 ELF Dynamic Feature Flags, DT_FEATURE_1

DTF_1_PARINIT

Indicates that the object requires partial initialization. See "Move Section".

DTF_1_CONFEXP

Identifies this object as a configuration alternative object generated by crle(1). This flag triggers the runtime linker to search for a configuration file $ORIGIN/ld.config.app-name. This flag has the same affect as DF_1_CONFALT.

Global Offset Table (Processor-Specific)

Position-independent code cannot, in general, contain absolute virtual addresses. Global offset tables hold absolute addresses in private data. Addresses are therefore available without compromising the position-independence and shareability of a program's text. A program references its global offset table using position-independent addressing and extracts absolute values. This technique redirects position-independent references to absolute locations.

Initially, the global offset table holds information as required by its relocation entries. After the system creates memory segments for a loadable object file, the runtime linker processes the relocation entries, some of which will be type R_SPARC_GLOB_DAT (for SPARC), or R_386_GLOB_DAT (for IA), referring to the global offset table.

The runtime linker determines the associated symbol values, calculates their absolute addresses, and sets the appropriate memory table entries to the proper values. Although the absolute addresses are unknown when the link-editor creates an object file, the runtime linker knows the addresses of all memory segments and can thus calculate the absolute addresses of the symbols contained therein.

If a program requires direct access to the absolute address of a symbol, that symbol will have a global offset table entry. Because the executable file and shared objects have separate global offset tables, a symbol's address can appear in several tables. The runtime linker processes all the global offset table relocations before giving control to any code in the process image. This processing ensures that absolute addresses are available during execution.

The table's entry zero is reserved to hold the address of the dynamic structure, referenced with the symbol _DYNAMIC. This symbol enables a program, such as the runtime linker, to find its own dynamic structure without having yet processed its relocation entries. This method is especially important for the runtime linker, because it must initialize itself without relying on other programs to relocate its memory image.

The system can choose different memory segment addresses for the same shared object in different programs. It can even choose different library addresses for different executions of the same program. Nonetheless, memory segments do not change addresses once the process image is established. As long as a process exists, its memory segments reside at fixed virtual addresses.

A global offset table's format and interpretation are processor-specific. For SPARC and IA processors, the symbol _GLOBAL_OFFSET_TABLE_ can be used to access the table. This symbol can reside in the middle of the .got section, allowing both negative and nonnegative subscripts into the array of addresses. The symbol type is an array of Elf32_Addr for 32-bit code, and an array of Elf64_Addr for 64-bit code:

extern  Elf32_Addr  _GLOBAL_OFFSET_TABLE_[];
extern  Elf64_Addr  _GLOBAL_OFFSET_TABLE_[];

Procedure Linkage Table (Processor-Specific)

The global offset table converts position-independent address calculations to absolute locations. Similarly the procedure linkage table converts position-independent function calls to absolute locations. The link-editor cannot resolve execution transfers such as function calls from one executable or shared object to another. So, the link-editor arranges to have the program transfer control to entries in the procedure linkage table. The runtime linker thus redirects the entries without compromising the position-independence and shareability of the program's text. Executable files and shared object files have separate procedure linkage tables.

SPARC: 32-bit Procedure Linkage Table

For 32-bit SPARC dynamic objects, the procedure linkage table resides in private data. The runtime linker determines the absolute addresses of the destinations and modifies the procedure linkage table's memory image accordingly.

The first four procedure linkage table entries are reserved. The original contents of these entries are unspecified, despite the example shown in Table 7-47. Each entry in the table occupies 3 words (12 bytes), and the last table entry is followed by a nop instruction.

A relocation table is associated with the procedure linkage table. The DT_JMP_REL entry in the _DYNAMIC array gives the location of the first relocation entry. The relocation table has one entry, in the same sequence, for each non-reserved procedure linkage table entry. The relocation type of each of these entries is R_SPARC_JMP_SLOT. The relocation offset specifies the address of the first byte of the associated procedure linkage table entry. The symbol table index refers to the appropriate symbol.

To illustrate procedure linkage tables, Table 7-47 shows four entries: two of the four initial reserved entries, the third is a call to name101, and the fourth entry is a call to name102. The example assumes that the entry for name102 is the table's last entry and shows the following nop instruction. The left column shows the instructions from the object file before dynamic linking. The right column demonstrates a possible way the runtime linker might fix the procedure linkage table entries.

Table 7-47 SPARC: Procedure Linkage Table Example

.PLT0:
    unimp
    unimp
    unimp
.PLT1:
    unimp
    unimp
    unimp

.PLT0:
    save    %sp, -64, %sp
    call    runtime_linker
    nop
.PLT1:
    .word   identification
    unimp
    unimp

.PLT101:
    sethi   (.-.PLT0), %g1
    ba,a    .PLT0
    nop
.PLT102:
    sethi   (.-.PLT0), %g1
    ba,a    .PLT0
    nop

    nop

.PLT101:
    nop
    ba,a    name101
    nop
.PLT102:
    sethi   (.-.PLT0), %g1
    sethi   %hi(name102), %g1
    jmpl    %g1+%lo(name102), %g0
    
    nop