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
$ORIGIN processing required
Symbolic symbol resolution required.
Text relocations exist.
Non-lazy binding required.
Indicates that the object requires $ORIGIN processing. See "Locating Associated Dependencies".
Indicates that the object contains symbolic bindings that were applied during its link-edit. See "Using -Bsymbolic".
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".
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
Perform complete relocation processing.
Indicate object is a member of a group.
Object cannot be deleted from a process.
Ensure immediate loading of filtees.
Objects' initialization occurs first.
Object can not be used with dlopen(3DL).
$ORIGIN processing required.
Direct bindings enabled
Object is an interposer
Ignore default library search path
Object cannot be dumped with dldump(3DL)
Object is a configuration alternative.
Filtee terminates filter's search.
Displacement relocation done.
Displacement relocation pending.
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".
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".
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.
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".
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.
Indicates that the object requires $ORIGIN processing. See "Locating Associated Dependencies".
Indicates that the object should use direct binding information. See "Direct Binding".
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".
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".
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.
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".
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".
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
Identify lazy loaded dependency.
Identify group dependency.
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".
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
Partial initialization is required.
A Configuration file is expected.
Indicates that the object requires partial initialization. See "Move Section".
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
|Object File||Memory Segment|