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 -B symbolic.

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.

DF_STATIC_TLS

Indicates that the object contains code using a static thread-local storage scheme. Static thread-local storage can not be used in objects that are dynamically loaded, either using dlopen(3DL), or using lazy loading. Because of this restriction, the link-editor does not support the creation of a shared object that requires static thread-local storage.

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 ignores 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 is not 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 Filtee 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.

DF_1_NODIRECT

Indicates that this object contains symbols that can not be directly bound to. See Defining Additional Symbols.

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 x86), 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 x86 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.