X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?p=pintos-anon;a=blobdiff_plain;f=specs%2Fsysv-abi-update.html%2Fch5.dynamic.html;fp=specs%2Fsysv-abi-update.html%2Fch5.dynamic.html;h=da7bfb6bc4d3c11c47a33957cee30c67461411eb;hp=0000000000000000000000000000000000000000;hb=8af06d1fd50343e17229618ef4d2693193b2b3d9;hpb=d0d14ca50fbac167253e1e1d8d806bfd749a5e8a
diff --git a/specs/sysv-abi-update.html/ch5.dynamic.html b/specs/sysv-abi-update.html/ch5.dynamic.html
new file mode 100644
index 0000000..da7bfb6
--- /dev/null
+++ b/specs/sysv-abi-update.html/ch5.dynamic.html
@@ -0,0 +1,1250 @@
+
+Dynamic Linking
+
Dynamic Linking
+
+
Program Interpreter
+An executable file that participates in
+dynamic linking shall have one
+PT_INTERP program header element.
+During
+exec(BA_OS),
+the system retrieves a path name from the PT_INTERP
+segment and creates the initial process image from
+the interpreter file's segments. That is,
+instead of using the original executable file's
+segment images, the system composes a memory
+image for the interpreter.
+It then is the interpreter's responsibility to
+receive control from the system and provide an
+environment for the application program.
+
+As ``Process Initialization'' in Chapter 3 of the
+processor supplement mentions,
+the interpreter receives control in one of two ways.
+First, it may receive a file descriptor
+to read the executable file, positioned at the beginning.
+It can use this file descriptor to read and/or map the executable
+file's segments into memory.
+Second, depending on the executable file format, the system
+may load the executable file into memory instead of giving the
+interpreter an open file descriptor.
+With the possible exception of the file descriptor,
+the interpreter's initial process state matches
+what the executable file would have received.
+The interpreter itself may not require a second interpreter.
+An interpreter may be either a shared object
+or an executable file.
+
+-
+A shared object (the normal case) is loaded as
+position-independent, with addresses that may vary
+from one process to another; the system creates its segments
+in the dynamic segment area used by
mmap(KE_OS) and related services
+[See ``Virtual Address Space'' in Chapter 3 of the processor
+supplement].
+Consequently, a shared object interpreter typically will
+not conflict with the original executable file's
+original segment addresses.
+ -
+An executable file may be loaded at fixed addresses;
+if so, the system creates its segments
+using the virtual addresses from the program header table.
+Consequently, an executable file interpreter's
+virtual addresses may collide with the
+first executable file; the interpreter is responsible
+for resolving conflicts.
+
+
+Dynamic Linker
+When building an executable file that uses dynamic linking,
+the link editor adds a program header element of type
+PT_INTERP to an executable file, telling the system to invoke
+the dynamic linker as the program interpreter.
+
+
+The locations of the system provided dynamic
+linkers are processor specific.
+
+Exec(BA_OS)
+and the dynamic linker cooperate to
+create the process image for the program, which entails
+the following actions:
+
+-
+Adding the executable file's memory segments to the process image;
+
-
+Adding shared object memory segments to the process image;
+
-
+Performing relocations for the executable file and its
+shared objects;
+
-
+Closing the file descriptor that was used to read the executable file,
+if one was given to the dynamic linker;
+
-
+Transferring control to the program, making it look as if
+the program had received control directly from
+
exec(BA_OS).
+
+
+The link editor also constructs various data
+that assist the dynamic linker
+for executable and shared object files.
+As shown above in
+``Program Header'',
+this data resides
+in loadable segments, making them available during execution.
+(Once again, recall the exact segment contents are processor-specific.
+See the processor supplement for complete information).
+
+-
+A
.dynamic section with type SHT_DYNAMIC
+holds various data.
+The structure residing at the
+beginning of the section holds the addresses
+of other dynamic linking information.
+ -
+The
.hash section with type SHT_HASH
+holds a symbol hash table.
+ -
+The
.got and .plt sections with type
+SHT_PROGBITS
+hold two separate tables:
+the global offset table and the procedure linkage table.
+Chapter 3 discusses how programs use the global offset table
+for position-independent code.
+Sections below explain how the dynamic linker uses
+and changes the tables to create memory images for object files.
+
+
+Because every ABI-conforming program imports the basic system
+services from a shared object library [See ``System Library''
+in Chapter 6], the dynamic linker participates in every
+ABI-conforming program execution.
+
+As
+`Program Loading'' explains in the processor supplement,
+shared objects may occupy
+virtual memory addresses that are different from the addresses recorded
+in the file's program header table.
+The dynamic linker relocates the memory image, updating
+absolute addresses before the application gains control.
+Although the absolute address values would be correct
+if the library were loaded at
+the addresses specified in the program header table, this normally
+is not the case.
+
+If the process environment [see exec(BA_OS)]
+contains a variable named LD_BIND_NOW
+with a non-null value, the dynamic linker processes
+all relocations before transferring control to the program.
+For example, all the following environment entries
+would specify this behavior.
+
+-
+
LD_BIND_NOW=1
+ -
+
LD_BIND_NOW=on
+ -
+
LD_BIND_NOW=off
+
+Otherwise, LD_BIND_NOW either
+does not occur in the environment or has a null value.
+The dynamic linker is permitted to evaluate procedure linkage table
+entries lazily, thus avoiding symbol resolution and relocation
+overhead for functions that are not called.
+See ``Procedure Linkage Table'' in this chapter of the processor
+supplement for more information.
+
+Dynamic Section
+If an object file participates in dynamic linking,
+its program header table will have an element of type
+PT_DYNAMIC.
+This ``segment'' contains the .dynamic section.
+A special symbol, _DYNAMIC,
+labels the section, which contains
+an array of the following structures.
+
+Figure 5-9: Dynamic Structure
+
+
+
+typedef struct {
+ Elf32_Sword d_tag;
+ union {
+ Elf32_Word d_val;
+ Elf32_Addr d_ptr;
+ } d_un;
+} Elf32_Dyn;
+
+extern Elf32_Dyn _DYNAMIC[];
+
+typedef struct {
+ Elf64_Sxword d_tag;
+ union {
+ Elf64_Xword d_val;
+ Elf64_Addr d_ptr;
+ } d_un;
+} Elf64_Dyn;
+
+extern Elf64_Dyn _DYNAMIC[];
+
+
+
+
+For each object with this type, d_tag
+controls the interpretation of d_un.
+
+d_val-
+These objects represent integer values with various
+interpretations.
+
d_ptr-
+These objects represent program virtual addresses.
+As mentioned previously, a file's virtual addresses
+might not match the memory virtual addresses during execution.
+When interpreting addresses contained in the dynamic
+structure, the dynamic linker computes actual addresses,
+based on the original file value and the memory base address.
+For consistency, files do not
+contain relocation entries to ``correct'' addresses in the dynamic
+structure.
+
+
+
+To make it simpler for tools to interpret the contents of
+dynamic section entries, the value of each tag, except for those in
+two special compatibility ranges,
+will determine the interpretation of the d_un
+union. A tag whose value is an even number
+indicates a dynamic section entry that uses d_ptr.
+A tag whose value is an odd number indicates a dynamic section entry
+that uses d_val or that uses neither d_ptr
+nor d_val. Tags whose values are less
+than the special value DT_ENCODING and tags
+whose values fall between DT_HIOS and
+DT_LOPROC do not follow these rules.
+
+The following table summarizes the tag requirements
+for executable and shared object files.
+If a tag is marked ``mandatory'', the dynamic linking
+array for an ABI-conforming file must have an entry of that type.
+Likewise, ``optional'' means an entry for the tag may appear
+but is not required.
+
+Figure 5-10: Dynamic Array Tags, d_tag
+
+
+| Name |
+Value |
+d_un |
+Executable |
+Shared Object |
+
+DT_NULL |
+0 |
+ignored |
+mandatory |
+mandatory |
+
+
+DT_NEEDED |
+1 |
+d_val |
+optional |
+optional |
+
+
+DT_PLTRELSZ |
+2 |
+d_val |
+optional |
+optional |
+
+
+DT_PLTGOT |
+3 |
+d_ptr |
+optional |
+optional |
+
+
+DT_HASH |
+4 |
+d_ptr |
+mandatory |
+mandatory |
+
+
+DT_STRTAB |
+5 |
+d_ptr |
+mandatory |
+mandatory |
+
+
+DT_SYMTAB |
+6 |
+d_ptr |
+mandatory |
+mandatory |
+
+
+DT_RELA |
+7 |
+d_ptr |
+mandatory |
+optional |
+
+
+DT_RELASZ |
+8 |
+d_val |
+mandatory |
+optional |
+
+
+DT_RELAENT |
+9 |
+d_val |
+mandatory |
+optional |
+
+
+DT_STRSZ |
+10 |
+d_val |
+mandatory |
+mandatory |
+
+
+DT_SYMENT |
+11 |
+d_val |
+mandatory |
+mandatory |
+
+
+DT_INIT |
+12 |
+d_ptr |
+optional |
+optional |
+
+
+DT_FINI |
+13 |
+d_ptr |
+optional |
+optional |
+
+
+DT_SONAME |
+14 |
+d_val |
+ignored |
+optional |
+
+
+DT_RPATH* |
+15 |
+d_val |
+optional |
+ignored |
+
+
+DT_SYMBOLIC* |
+16 |
+ignored |
+ignored |
+optional |
+
+
+DT_REL |
+17 |
+d_ptr |
+mandatory |
+optional |
+
+
+DT_RELSZ |
+18 |
+d_val |
+mandatory |
+optional |
+
+
+DT_RELENT |
+19 |
+d_val |
+mandatory |
+optional |
+
+
+DT_PLTREL |
+20 |
+d_val |
+optional |
+optional |
+
+
+DT_DEBUG |
+21 |
+d_ptr |
+optional |
+ignored |
+
+
+DT_TEXTREL* |
+22 |
+ignored |
+optional |
+optional |
+
+
+DT_JMPREL |
+23 |
+d_ptr |
+optional |
+optional |
+
+
+DT_BIND_NOW* |
+24 |
+ignored |
+optional |
+optional |
+
+
+DT_INIT_ARRAY |
+25 |
+d_ptr |
+optional |
+optional |
+
+
+DT_FINI_ARRAY |
+26 |
+d_ptr |
+optional |
+optional |
+
+
+DT_INIT_ARRAYSZ |
+27 |
+d_val |
+optional |
+optional |
+
+
+DT_FINI_ARRAYSZ |
+28 |
+d_val |
+optional |
+optional |
+
+DT_RUNPATH |
+29 |
+d_val |
+optional |
+optional |
+
+DT_FLAGS |
+30 |
+d_val |
+optional |
+optional |
+
+
+DT_ENCODING |
+32 |
+unspecified |
+unspecified |
+unspecified |
+
+
+DT_PREINIT_ARRAY |
+32 |
+d_ptr |
+optional |
+ignored |
+
+
+DT_PREINIT_ARRAYSZ |
+33 |
+d_val |
+optional |
+ignored |
+
+
+DT_LOOS |
+0x6000000D |
+unspecified |
+unspecified |
+unspecified |
+
+
+DT_HIOS |
+0x6ffff000 |
+unspecified |
+unspecified |
+unspecified |
+
+
+DT_LOPROC |
+0x70000000 |
+unspecified |
+unspecified |
+unspecified |
+
+
+DT_HIPROC |
+0x7fffffff |
+unspecified |
+unspecified |
+unspecified |
+
+
+
+* Signifies an entry that is at level 2.
+
+
+DT_NULL-
+An entry with a
DT_NULL tag marks the end of the
+_DYNAMIC array.
+ DT_NEEDED-
+This element holds the string table offset of a null-terminated string,
+giving the name of a needed library.
+The offset is an index into the table recorded in the
DT_STRTAB code.
+See
+``Shared Object Dependencies''
+for more
+information about these names.
+The dynamic array may contain multiple entries with
+this type.
+These entries' relative order is significant, though their
+relation to entries of other types is not.
+ DT_PLTRELSZ-
+This element holds the total size, in bytes,
+of the relocation entries associated with the procedure linkage table.
+If an entry of type
DT_JMPREL is present, a
+DT_PLTRELSZ must accompany it.
+ DT_PLTGOT-
+This element holds an address associated with the procedure linkage table
+and/or the global offset table.
+See this section in the processor supplement for details.
+
DT_HASH-
+This element holds the address of the symbol hash table,
+described in
+``Hash Table''.
+This hash table refers to the symbol table referenced by the
DT_SYMTAB
+element.
+ DT_STRTAB-
+This element holds the address of the string table,
+described in Chapter 4.
+Symbol names, library names, and other strings reside
+in this table.
+
DT_SYMTAB-
+This element holds the address of the symbol table,
+described in the first part of this chapter, with
Elf32_Sym
+entries for the 32-bit class of files and Elf64_Sym
+entries for the 64-bit class of files.
+ DT_RELA-
+This element holds the address of a relocation table,
+described in Chapter 4.
+Entries in the table have explicit addends, such as
+
Elf32_Rela for the 32-bit file class
+or Elf64_Rela for the 64-bit file class.
+An object file may have multiple relocation sections.
+When building the relocation table for an
+executable or shared object file, the link editor
+catenates those sections to form a single table.
+Although the sections remain independent in the object file,
+the dynamic linker sees a single table.
+When the dynamic linker creates the process image for
+an executable file or adds a shared object to the
+process image, it reads the relocation table and performs
+the associated actions.
+If this element is present, the dynamic structure must also have
+DT_RELASZ and DT_RELAENT elements.
+When relocation is ``mandatory'' for a file, either
+DT_RELA or DT_REL may occur (both are permitted but not required).
+ DT_RELASZ-
+This element holds the total size, in bytes, of the
+
DT_RELA relocation table.
+ DT_RELAENT-
+This element holds the size, in bytes, of the
+
DT_RELA relocation entry.
+ DT_STRSZ-
+This element holds the size, in bytes, of the string table.
+
DT_SYMENT-
+This element holds the size, in bytes, of a symbol table entry.
+
DT_INIT-
+This element holds the address of the initialization function,
+discussed in
+``Initialization and Termination Functions''
+below.
+
DT_FINI-
+This element holds the address of the termination function,
+discussed in
+``Initialization and Termination Functions''
+below.
+
DT_SONAME-
+This element holds the string table offset of a null-terminated string,
+giving the name of the shared object.
+The offset is an index into the table recorded in the
DT_STRTAB entry.
+See
+``Shared Object Dependencies''
+below for more
+information about these names.
+
+ DT_RPATH-
+This element holds the string table offset of a null-terminated search
+library search path string discussed in
+``Shared Object Dependencies''.
+The offset is an index into the table recorded in the
+
DT_STRTAB entry. This entry is at level 2. Its
+use has been superseded by DT_RUNPATH.
+ DT_SYMBOLIC-
+This element's presence in a shared object library alters
+the dynamic linker's symbol resolution algorithm for
+references within the library.
+Instead of starting a symbol search with the
+executable file, the dynamic linker starts from the
+shared object itself.
+If the shared object fails to supply the referenced
+symbol, the dynamic linker then searches the
+executable file and other shared objects as usual.
+This entry is at level 2. Its use has been superseded
+by the
DF_SYMBOLIC flag.
+ DT_REL-
+This element is similar to
DT_RELA,
+except its table has implicit addends, such as
+Elf32_Rel for the 32-bit file class
+or Elf64_Rel for the 64-bit file class.
+If this element is present, the dynamic structure must also have
+DT_RELSZ and DT_RELENT elements.
+ DT_RELSZ-
+This element holds the total size, in bytes, of the
+
DT_REL relocation table.
+ DT_RELENT-
+This element holds the size, in bytes, of the
+
DT_REL relocation entry.
+ DT_PLTREL-
+This member specifies the type of relocation entry
+to which the procedure linkage table refers.
+The
d_val member holds DT_REL or DT_RELA,
+as appropriate.
+All relocations in a procedure linkage table must use
+the same relocation.
+ DT_DEBUG-
+This member is used for debugging. Its contents are not specified
+for the ABI; programs that access this entry are not
+ABI-conforming.
+
DT_TEXTREL-
+This member's absence signifies that no
+relocation entry should cause a modification to a non-writable
+segment, as specified by the segment permissions in the program
+header table.
+If this member is present, one or more relocation entries might
+request modifications to a non-writable segment, and the dynamic
+linker can prepare accordingly.
+This entry is at level 2. Its use has been superseded
+by the
DF_TEXTREL flag.
+ DT_JMPREL-
+If present, this entry's
d_ptr
+member holds the address of relocation entries associated solely
+with the procedure linkage table.
+Separating these relocation entries lets the dynamic linker ignore
+them during process initialization, if lazy binding is enabled.
+If this entry is present, the related entries of types
+DT_PLTRELSZ and DT_PLTREL
+must also be present.
+ DT_BIND_NOW-
+If present in a shared object or executable, this entry
+instructs the dynamic linker to process all relocations
+for the object containing this entry before transferring
+control to the program.
+The presence of this entry takes
+precedence over a directive to use lazy binding for this object when
+specified through the environment or via
dlopen(BA_LIB).
+This entry is at level 2. Its use has been superseded
+by the DF_BIND_NOW flag.
+ DT_INIT_ARRAY-
+
+This element holds the address of the array of pointers to initialization
+functions,
+discussed in
+``Initialization and Termination Functions''
+below.
+
DT_FINI_ARRAY-
+This element holds the address of the array of pointers to termination
+functions,
+discussed in
+``Initialization and Termination Functions''
+below.
+
DT_INIT_ARRAYSZ-
+This element holds the size in bytes of the array of initialization
+functions pointed to by the
DT_INIT_ARRAY entry.
+If an object has a DT_INIT_ARRAY entry, it must
+also have a DT_INIT_ARRAYSZ entry.
+ DT_FINI_ARRAYSZ-
+This element holds the size in bytes of the array of termination
+functions pointed to by the
DT_FINI_ARRAY entry.
+If an object has a DT_FINI_ARRAY entry, it must
+also have a DT_FINI_ARRAYSZ entry.
+
+ DT_RUNPATH-
+This element holds the string table offset of a null-terminated
+library search path string discussed in
+``Shared Object Dependencies''.
+The offset is an index into the table recorded in the
+
DT_STRTAB entry.
+ DT_FLAGS-
+This element holds flag values specific to the object being
+loaded. Each flag value will have the name
DF_flag_name.
+Defined values and their meanings are described below.
+All other values are reserved.
+ DT_PREINIT_ARRAY-
+This element holds the address of the array of pointers to pre-initialization
+functions,
+discussed in
+``Initialization and Termination Functions''
+below. The
DT_PREINIT_ARRAY table is processed only
+in an executable file; it is ignored if contained in a shared object.
+ DT_PREINIT_ARRAYSZ-
+This element holds the size in bytes of the array of pre-initialization
+functions pointed to by the
DT_PREINIT_ARRAY entry.
+If an object has a DT_PREINIT_ARRAY entry, it must
+also have a DT_PREINIT_ARRAYSZ entry. As with
+DT_PREINIT_ARRAY, this entry is ignored if it appears
+in a shared object.
+ DT_ENCODING-
+Values greater than or equal to
DT_ENCODING
+and less than DT_LOOS
+follow the rules for the interpretation of the d_un union
+described above.
+ DT_LOOS through DT_HIOS-
+Values in this inclusive range
+are reserved for operating system-specific semantics.
+All such values follow the rules for the interpretation of the
+
d_un union described above.
+ DT_LOPROC through DT_HIPROC-
+Values in this inclusive range
+are reserved for processor-specific semantics. If meanings
+are specified, the processor supplement explains them.
+All such values follow the rules for the interpretation of the
+
d_un union described above.
+
+
+Except for the DT_NULL element at the end of the array,
+and the relative order of DT_NEEDED
+elements, entries may appear in any order.
+Tag values not appearing in the table are reserved.
+
+
+Figure 5-11: DT_FLAGS values
+
+
+| Name |
+Value |
+
+DF_ORIGIN |
+0x1 |
+
+
+DF_SYMBOLIC |
+0x2 |
+
+
+DF_TEXTREL |
+0x4 |
+
+
+DF_BIND_NOW |
+0x8 |
+
+
+DF_STATIC_TLS |
+0x10 |
+
+
+
+
+DF_ORIGIN-
+This flag signifies that the object being loaded may make reference
+to the
$ORIGIN substitution string (see ``Substitution Sequences'').
+The dynamic linker must determine the pathname of the object
+containing this entry when the object is loaded.
+
+ DF_SYMBOLIC-
+If this flag is set in a shared object library,
+the dynamic linker's symbol resolution algorithm for
+references within the library is changed.
+Instead of starting a symbol search with the
+executable file, the dynamic linker starts from the
+shared object itself.
+If the shared object fails to supply the referenced
+symbol, the dynamic linker then searches the
+executable file and other shared objects as usual.
+
+
DF_TEXTREL-
+If this flag is not set, no
+relocation entry should cause a modification to a non-writable
+segment, as specified by the segment permissions in the program
+header table.
+If this flag is set, one or more relocation entries might
+request modifications to a non-writable segment, and the dynamic
+linker can prepare accordingly.
+
+
DF_BIND_NOW-
+If set in a shared object or executable, this flag
+instructs the dynamic linker to process all relocations
+for the object containing this entry before transferring
+control to the program.
+The presence of this entry takes
+precedence over a directive to use lazy binding for this object when
+specified through the environment or via
dlopen(BA_LIB).
+
+ DF_STATIC_TLS-
+If set in a shared object or executable,
+this flag instructs the dynamic linker to reject
+attempts to load this file dynamically.
+It indicates that the shared object or executable
+contains code using a static thread-local storage scheme.
+Implementations need not support any form of thread-local storage.
+
+
+Shared Object Dependencies
+When the link editor processes an archive library,
+it extracts library members and copies them into
+the output object file.
+These statically linked services are available during
+execution without involving the dynamic linker.
+Shared objects also provide services, and
+the dynamic linker must attach the proper shared object files to
+the process image for execution.
+
+When the dynamic linker creates the memory segments for
+an object file, the dependencies (recorded in
+DT_NEEDED entries of the dynamic structure)
+tell what shared objects are needed to
+supply the program's services.
+By repeatedly connecting referenced shared objects and
+their dependencies, the dynamic linker builds a complete process image.
+When resolving symbolic references, the dynamic linker
+examines the symbol tables with a breadth-first search.
+That is, it first looks at the symbol table of the
+executable program itself, then at the symbol tables
+of the DT_NEEDED entries (in order),
+and then at the second level DT_NEEDED entries, and
+so on. Shared object files must be readable by the process;
+other permissions are not required.
+
+
+Even when a shared object is referenced multiple
+times in the dependency list, the dynamic linker will
+connect the object only once to the process.
+
+
+Names in the dependency list are copies either of the
+DT_SONAME strings or the path names of the shared objects used to build
+the object file.
+For example, if the link editor builds an executable
+file using one shared object with a
+DT_SONAME entry of lib1
+and another shared object library with the path name
+/usr/lib/lib2, the executable file will contain
+lib1 and /usr/lib/lib2 in its dependency list.
+
+If a shared object name has one or more slash (/)
+characters anywhere in the name, such as /usr/lib/lib2
+or directory/file, the dynamic linker uses that string directly
+as the path name.
+If the name has no slashes, such as lib1,
+three facilities specify shared object path searching.
+
+
+
+-
+The dynamic array tag
DT_RUNPATH gives a string that
+holds a list of directories, separated by colons (:).
+For example, the string
+/home/dir/lib:/home/dir2/lib:
+tells the dynamic linker to search first the directory
+/home/dir/lib, then /home/dir2/lib,
+and then the current directory to find dependencies.
+
+The set of directories specified by a given DT_RUNPATH
+entry is used to find only the immediate dependencies
+of the executable or shared object containing the DT_RUNPATH
+entry. That is, it is used only for those dependencies contained in
+the DT_NEEDED entries of the dynamic structure containing
+the DT_RUNPATH entry, itself.
+One object's DT_RUNPATH entry does not affect the search
+for any other object's dependencies.
+
-
+A variable called
LD_LIBRARY_PATH
+in the process environment [see exec(BA_OS)]
+may hold a list of directories as above, optionally
+followed by a semicolon (;) and
+another directory list.
+The following values would be equivalent to the previous example:
+
+-
+
LD_LIBRARY_PATH=/home/dir/usr/lib:/home/dir2/usr/lib:
+ -
+
LD_LIBRARY_PATH=/home/dir/usr/lib;/home/dir2/usr/lib:
+ -
+
LD_LIBRARY_PATH=/home/dir/usr/lib:/home/dir2/usr/lib:;
+
+
+Although some programs (such as the link editor) treat the lists
+before and after the semicolon differently,
+the dynamic linker does not.
+Nevertheless, the dynamic linker accepts the semicolon
+notation, with the semantics described previously.
+
+All LD_LIBRARY_PATH directories are searched before those from
+DT_RUNPATH.
+
-
+Finally, if the other two groups of directories
+fail to locate the desired library, the dynamic linker searches
+the default directories,
/usr/lib or such other
+directories as may be specified by the ABI supplement for a
+given processor.
+
+
+
+When the dynamic linker is searching for shared objects, it is
+not a fatal error if an ELF file with the wrong attributes
+is encountered in the search. Instead, the dynamic linker
+shall exhaust the search of all paths before determining
+that a matching object could not be found. For this determination,
+the relevant attributes are contained in the following ELF header fields:
+e_ident[EI_DATA],
+e_ident[EI_CLASS],
+e_ident[EI_OSABI],
+e_ident[EI_ABIVERSION],
+e_machine,
+e_type, e_flags
+and e_version.
+
+
+For security, the dynamic linker ignores
+LD_LIBRARY_PATH for set-user and
+set-group ID programs.
+It does, however, search DT_RUNPATH directories
+and the default directories.
+The same restriction may be applied to processes that have more than
+minimal privileges on systems with installed extended security
+mechanisms.
+
+
+A fourth search facility, the dynamic array tag DT_RPATH,
+has been moved to level 2 in the ABI.
+It provides a colon-separated list of directories to search.
+Directories specified by DT_RPATH are searched
+before directories specified by LD_LIBRARY_PATH.
+
+If both DT_RPATH and DT_RUNPATH
+entries appear in a single object's dynamic array,
+the dynamic linker processes only the DT_RUNPATH
+entry.
+
+
+Substitution Sequences
+Within a string provided by dynamic array entries with the
+DT_NEEDED or DT_RUNPATH tags and in
+pathnames passed as parameters to the dlopen() routine, a
+dollar sign ($) introduces a substitution sequence.
+This sequence consists of the dollar sign immediately followed
+by either the longest name sequence or a name contained
+within left and right braces ({) and (}).
+A name is a sequence of bytes that start with either a letter or
+an underscore followed by zero or more letters, digits or underscores.
+If a dollar sign is not immediately followed by a name or a
+brace-enclosed name, the behavior of the dynamic linker is unspecified.
+
+If the name is ``ORIGIN'', then the substitution
+sequence is replaced by the dynamic linker with the absolute
+pathname of the directory in which the object containing the
+substitution sequence originated. Moreover, the pathname will
+contain no symbolic links or use of ``.'' or
+``..'' components.
+Otherwise (when the name is not ``ORIGIN'')
+the behavior of the dynamic linker is unspecified.
+
+When the dynamic linker loads an object that uses $ORIGIN,
+it must calculate the pathname of the directory containing the object.
+Because this calculation can be computationally expensive,
+implementations may want to avoid the calculation for objects
+that do not use $ORIGIN.
+If an object calls dlopen() with a string
+containing $ORIGIN and does not use $ORIGIN
+in one if its dynamic array entries,
+the dynamic linker may not have calculated the
+pathname for the object until the dlopen() actually
+occurs. Since the application may have changed its current
+working directory before the dlopen() call,
+the calculation may not yield the correct result.
+To avoid this possibility, an object may signal its intention
+to reference $ORIGIN by setting the
+DF_ORIGIN flag.
+An implementation may reject an attempt to use $ORIGIN
+within a dlopen() call from an object that
+did not set the DF_ORIGIN flag and did not
+use $ORIGIN within its dynamic array.
+
+
+For security, the dynamic linker does not allow use of
+$ORIGIN substitution sequences for set-user and
+set-group ID programs. For such sequences that appear
+within strings specified by DT_RUNPATH dynamic
+array entries, the specific search path containing the
+$ORIGIN sequence is ignored (though other
+search paths in the same string are processed).
+$ORIGIN sequences within a DT_NEEDED
+entry or path passed as a parameter to dlopen()
+are treated as errors.
+The same restrictions may be applied to processes that have more than
+minimal privileges on systems with installed extended security
+mechanisms.
+
+
+Global Offset Table
+
+
+This section requires processor-specific information.
+The System V Application Binary Interface supplement
+for the desired processor describes the details.
+
+
+
Procedure Linkage Table
+
+
+This section requires processor-specific information.
+The System V Application Binary Interface supplement
+for the desired processor describes the details.
+
+
+
Hash Table
+A hash table of Elf32_Word
+objects supports symbol table access. The same table
+layout is used for both the 32-bit and 64-bit file class.
+Labels appear below
+to help explain the hash table organization,
+but they are not part of the specification.
+
+Figure 5-12: Symbol Hash Table
+
+
+nbucket |
+nchain |
+bucket[0]
. . .
bucket[nbucket-1] |
+chain[0]
. . .
chain[nchain-1] |
+
+
+
+The bucket array contains nbucket
+entries, and the chain array contains nchain
+entries; indexes start at 0.
+Both bucket and chain
+hold symbol table indexes.
+Chain table entries parallel the symbol table.
+The number of symbol table entries should equal
+nchain;
+so symbol table indexes also select chain table entries.
+A hashing function (shown below) accepts a symbol name and returns a
+value that may be used to compute a bucket index.
+Consequently, if the hashing function returns the value
+x for some name, bucket[x%nbucket] gives
+an index, y,
+into both the symbol table and the chain table.
+If the symbol table entry is not the one desired,
+chain[y] gives the next symbol table entry
+with the same hash value.
+One can follow the chain
+links until either the selected symbol table entry
+holds the desired name or the chain entry contains the value
+STN_UNDEF.
+
+Figure 5-13: Hashing Function
+
+
+
+unsigned long
+elf_hash(const unsigned char *name)
+{
+ unsigned long h = 0, g;
+ while (*name)
+ {
+ h = (h << 4) + *name++;
+ if (g = h & 0xf0000000)
+ h ^= g >> 24;
+ h &= ~g;
+ }
+ return h;
+}
+
+
+
+
+Initialization and Termination Functions
+After the dynamic linker has built the process image
+and performed the relocations, each shared object and the executable
+file get the opportunity to execute some initialization functions.
+All shared object initializations happen before the executable
+file gains control.
+
+Before the initialization functions for any object A is called, the initialization
+functions for any other objects that object A depends on are called.
+For these purposes, an object A depends on another object B,
+if B appears in A's list of needed objects (recorded in the DT_NEEDED
+entries of the dynamic structure).
+The order of initialization for circular dependencies is undefined.
+
+The initialization of objects occurs by recursing through the needed
+entries of each object.
+The initialization functions for an object are invoked after the needed
+entries for that object have been processed.
+The order of processing among the entries of a particular list of
+needed objects is unspecified.
+
+
+Each processor supplement may optionally further restrict
+the algorithm used to determine the order of initialization.
+Any such restriction, however, may not conflict with
+the rules described by this specification.
+
+
+The following example illustrates two of the possible correct orderings
+which can be generated for the example NEEDED lists.
+In this example the a.out is dependent on b, d, and e.
+b is dependent on d and f, while d is dependent on e and g.
+From this information a dependency graph can be drawn.
+The above algorithm on initialization will then allow the following
+specified initialization orderings among others.
+
+Figure 5-14: Initialization Ordering Example
+
+
+
+
+
+Similarly, shared objects and executable files may have termination
+functions, which are executed with the
+atexit(BA_OS) mechanism after the base process begins its
+termination sequence.
+The termination functions for any object A must be called before
+the termination functions for any other objects that object A depends
+on. For these purposes, an object A depends on another object B,
+if B appears in A's list of needed objects (recorded in the DT_NEEDED
+entries of the dynamic structure).
+The order of termination for circular dependencies is undefined.
+
+
+Finally, an executable file may have pre-initialization functions.
+These functions are executed after the dynamic linker has built
+the process image and performed relocations but before any shared
+object initialization functions. Pre-initialization functions are
+not permitted in shared objects.
+
+
+Complete initialization of system libraries may not have occurred when
+pre-initializations are executed, so some features of the system
+may not be available to pre-initialization code. In general,
+use of pre-initialization code can be considered portable only
+if it has no dependencies on system libraries.
+
+
+The dynamic linker ensures that it will not execute any initialization,
+pre-initialization, or termination functions more than once.
+
+Shared objects designate their
+initialization and termination code in one of two ways.
+First, they may specify the address of a function to execute
+via the
+DT_INIT
+and
+DT_FINI
+entries in the dynamic structure, described in
+``Dynamic Section''
+above.
+
+
+Note that the address of a function
+need not be the same as a pointer to a function
+as defined by the processor supplement.
+
+
+Shared objects may also (or instead) specify the address and size of
+an array of function pointers. Each element of this
+array is a pointer to a function to be executed by the dynamic linker.
+Each array element is the size of a pointer in the
+programming model followed by the object containing
+the array. The address of the array of initialization
+function pointers is specified by the DT_INIT_ARRAY
+entry in the dynamic structure. Similarly, the address of
+the array of pre-initialization functions is specified by
+DT_PREINIT_ARRAY and the address of the array
+of termination functions is specified by DT_FINI_ARRAY.
+The size of each array is specified by the DT_INIT_ARRAYSZ,
+DT_PREINIT_ARRAYSZ, and DT_FINI_ARRAYSZ
+entries.
+
+
+
+The addresses contained in the initialization and termination arrays
+are function pointers as defined by the processor supplement for
+each processor. On some architectures, a function pointer may not
+contain the actual address of the function.
+
+
+
+The functions pointed to in the arrays
+specified by DT_INIT_ARRAY and by DT_PREINIT_ARRAY
+are executed by the dynamic
+linker in the same order in which their addresses appear in
+the array; those specified by DT_FINI_ARRAY
+are executed in reverse order.
+
+If an object contains both DT_INIT
+and DT_INIT_ARRAY entries, the function referenced
+by the DT_INIT entry is processed before those
+referenced by the DT_INIT_ARRAY entry for that object.
+If an object contains both DT_FINI
+and DT_FINI_ARRAY entries, the functions referenced
+by the DT_FINI_ARRAY entry are processed before the one
+referenced by the DT_FINI entry for that object.
+
+
+Although the
+atexit(BA_OS)
+termination processing normally will be done,
+it is not guaranteed to have executed upon process death.
+In particular, the process will not execute the termination processing
+if it calls _exit [see
+exit(BA_OS)]
+or if the process dies because it received a signal
+that it neither caught nor ignored.
+
+
+
+The processor supplement for each processor specifies whether the
+dynamic linker is responsible for calling the executable file's
+initialization function or registering the executable file's
+termination function with
+atexit(BA_OS).
+Termination functions specified by users via the
+atexit(BA_OS)
+mechanism
+must be executed before any termination functions of shared objects.
+
+
+
+
+
+
+© 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc. All rights reserved.
+
+
+