dld.sl(5)

Shared Libraries

Shared libraries are executable files created with the -b option to ld (see ld(1)). They must contain position-independent code (PIC) that can be mapped anywhere in the address space of a process and executed with minimal relocation. PIC can use PC-relative addressing modes and/or linkage tables. It is generated by default by the compilers on PA64 and by specifying the +z/+Z options on PA32. See the +help option to ld(1) or the HP-UX Linker and Libraries User's Guide manual for details on writing PIC in assembly language.

Incomplete Executables

An executable program linked with one or more shared libraries is called an incomplete executable.

When creating an executable (a.out) file from object files and libraries, the linker does not copy text (code) or data from the shared library into the output file. Instead, the dynamic loader maps the library into the address space of the process at run time. The linker binds all program references to shared library routines and data to entries in a linkage table, and relies on the dynamic loader to fill in the linkage table entries once the libraries have been mapped. This linkage table serves as a jump table for function calls.

Thread local storage is now supported. The dynamic loader will tally each shared library's thread local storage size as well as the program's thread local storage size. When all libraries are loaded, on PA32 the dynamic loader will either call a thread routine to set the thread pointer and allocate space for the initial thread or will call mmap() and lwp_setprivate() to allocate the space and setup the thread pointer. On PA64, the dynamic loader will invoke an initializer in the system library libc which will do the thread initialization, allocation of the initial thread, and set the thread pointer.

On previous PA32 releases, shared library data items referenced by the program were copied into the program executable file so that the data references could be resolved statically. Beginning with the Series 700/800 10.0 release, references to shared library data from the a.out are included in a linkage table and are resolved at run time.

Loading

An incomplete executable contains a list of path names of the shared libraries searched at link time. At run time, the dynamic loader attaches to the process all shared libraries that were linked with the program. The dynamic loader will attempt to load each library from the same directory in which it was found at link time. It is possible to change the shared library run time search path by specifying a dynamic path list. See PA32 Dynamic Path List and/or PA64 Dynamic Path List.

The text segment of a library is shared among all processes that use it. The data and bss segments are shared on a page-by-page basis. When a process first accesses (reads or writes) a data or bss page, a copy of that page is made for the process.

PA32 Dynamic Path List

There are two was to specify a dynamic path list :

The path list is a list of one or more path names separated by colons (:). The dynamic path list will work only for libraries specified with the -l or -l: options to ld. However, it can be enabled for libraries specified with a full path name using the -l option to chatr (see chatr(1)). If both +s and +b are used, their relative order on the command line indicates which path list will be searched first in compatibility mode. See the +help option to ld(1) or the HP-UX Linker and Libraries User's Guide manual for more details.

PA64 Dynamic Path List

For standard mode libraries (libraries built or linked with ld +std ), the dynamic loader will use dynamic path searching to find shared libraries whose names appear in a library list of the program or loaded shared libraries with no embedded / character. Dynamic path searching is enabled by default for these standard mode libraries or executables. If ld +noenvvar is specified, the dynamic loader will not look at any dyanmic path environment variables to find dependent shared libraries. This limits the dynamic path searching to the value of rpath and the default directories /usr/lib/pa20_64 and /usr/ccs/lib/pa20_64.

For compatibility mode libraries (libraries built or linked with ld +compat), the dynamic loader will only do dynamic path searching for these libraries if they were linked with -l or -l: and one of these were specified:

There are several ways to specify a dynamic path list :

The path list is a list of one or more path names separated by colons (:). The dynamic path list will work only for libraries specified with the -l or -l: options to ld. However, it can be enabled for libraries specified with a full path name using the -l option to chatr (see chatr(1)). If both +s and +b are used, their relative order on the command line indicates which path list will be searched first in compatibility mode. See the +help option to ld(1) or the HP-UX Linker and Libraries User's Guide manual for more details.

The dynamic loader will use these rules when determining which dynamic path list to use:

The rules change slightly when looking for dependent shared libraries.

Binding

The dynamic loader also resolves symbolic references between the executable and libraries. By default, function calls are trapped via the linkage table and bound on first reference. References to data symbols and other absolute address references cannot be trapped. They are bound on the first resolution of a function call that could potentially reference the object.

If the -B immediate option to ld is used, the loader binds all necessary references at startup time. This increases the startup cost of a program, but ensures that no more binding operations will be required later. Thus, better real-time response may result, and the risk of a later abort due to unresolved externals is eliminated.

The fastbind tool can be used to improve the start-up time of programs that use shared libraries (incomplete executables). The fastbind tool performs analysis on the shared library routines and data used to bind the symbols and stores this information in the executable file. The dynamic loader will notice that this information is available, and it will use this fastbind information to bind the symbols instead of the standard search method. For more details refer to fastbind(1) and the +help option to ld(1) or the HP-UX Linker and Libraries User's Guide manual.

Breadth-first Searching

This is only available on PA64. By default, the dynamic loader will do breadth-first searching when binding symbols. If the incomplete executable was linked with +compat or if a shl_load() is being executed, then depth-first searching is used. Breadth-first searching specifies that the dynamic loader will look for symbols starting with the incomplete executable followed by all loaded shared libraries in a left to right order until the symbol is found. For example, the incomplete executable is searched followed by all libraries in its library load list. Then the dependent shared libraries of the first library in the library load list list is searched, followed by the dependent shared libraries of the second library in the list, et cetera.

Depth-first Searching

This is the only search behavior on PA32 and is used on PA64 if doing a shl_load() or if the incomplete executable was linked with +compat. The dynamic loader will search the incomplete executable followed by the first library in its library load list. The first dependent library of this library is then searched, followed by the first dependent of this dependent, and so on. When there are no more dependents, the siblings and their dependents are searched until eventually the second library in the program's library load list is searched, followed by the first dependent of this library, et cetera.

Version Control

Since code from a shared library is mapped at run time from a separate shared library file, modifications to a shared library may alter the behavior of existing executables. In some cases, this may cause programs to operate incorrectly. Two means of version control is provided to solve this problem.

PA32 Explicit Loading and Binding

The duties of the dynamic loader as described above are all performed automatically, although they can be controlled somewhat by appropriate options to ld. The dynamic loader can also be accessed programmatically. The reserved symbol __dld_loc, which is defined in crt0.o, points to a jump table within the dynamic loader. The routines described under shl_load(3X) provide a portable interface that allows the programmer to explicitly attach a shared library to the process at run time, to calculate the addresses of symbols defined within shared libraries, and to detach the library when done.

PA64 Explicit Loading and Binding

The duties of the dynamic loader as described above are all performed automatically, although they can be controlled somewhat by appropriate options to ld. The dynamic loader can also be accessed programmatically. The routines described under shl_load(3X), dlclose(3C), dlerror(3C), dlget(3C), dlmodinfo(3C), dlopen(3C), and dlsym(3C) provide a portable interface that allows the programmer to explicitly attach a shared library to the process at run time, to calculate the addresses of symbols defined within shared libraries, and to detach the library when done.

Global Symbol Table

The global symbol table mechanism is designed as a performance enhancement option. Enabling this mechanism causes the creation of a global symbol table which speeds up symbol lookup, by eliminating the need to scan all loaded libraries in order to find a symbol. This is particularly effective for applications with large numbers of shared libraries. This mechanism is off by default.

The global symbol table is implemented using a hash table. Under this mechanism, whenever a library is loaded (either implicitly or by using dlopen() or shl_load()), the mechanism hashes the library's exports and places them into this table. When a library is unloaded, the mechanism looks up the library's exports in the table and removes them.

The hash table does not contain entries for symbols defined by shl_definesym(). User-defined symbols must therefore be handled separately.

Enabling the mechanism causes dld to use more memory and impacts the performance of the dlopen(), dlclose(), shl_load(), and shl_unload() API calls.

With the global symbol table, the dynamic loader may need to perform a large number of hashing operations to locate symbols. Performing this hash function may cost considerable time, especially when symbol names are very long (C++ programs). To speed up dld, computing hash values can be off-loaded to the linker.

Use the +gst options, +gst, +gstbuckets (32-bit only), +gstsize, +nodynhash (64-bit only), and +plabel_cache, (32-bit only) to control the behavior of the global symbol table hash mechanism. See the ld(1) and chatr(1) commands for information on these options.

With these options, you can tune the size of the hash table and number of buckets per entry to reach a balance of performance and memory use. To maximize for performance, tune the table size for an average chain length of one. For maximum memory use, at the expense of performance, tune the size of the table to minimize the number of empty entries. In general, use prime numbers for the table size. The mechanism provide default values of table size, 1103, and number of buckets, 3.

To get statistical information about hash table performance, set the environment variable _HP_DLDOPTS to contain the -symtab_stat option. This option provideds a message for each library that contains the following information:

System Tools:

Miscellaneous:

Texts and Tutorials