dld.so(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. The HP compilers generate PIC by default.

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

Two thread local storage models are supported: static and dynamic, which is controlled by a compiler option +tls=static/dynamic. The default is +tls=dynamic. Shared libraries built with the dynamic model can be loaded using dlopen(3C) and shl_load(3X) APIs. An attempt to load a shared library built with the static model using dlopen(3C) or shl_load(3X) APIs will result in the following error:

The dynamic loader tallies each shared library's thread local storage size as well as the program's thread local storage size. When all libraries are loaded, the dynamic loader invokes an initializer in the system library libc, which does the thread initialization, allocation of the initial thread, and sets the thread pointer.

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 attempts 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. (For PA-RISC 32-bit compatibility mode information, see Dynamic Path List.)

The text segment of a library is shared among all processes that use it. The data and bss (uninitialized data) segments are loaded 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.

Dynamic Path List

For default mode libraries, the dynamic loader uses 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 libraries or executables. If ld +noenvvar is specified, the dynamic loader does not look at any dynamic path environment variables to find dependent shared libraries. This limits the dynamic path searching to the value of rpath (run time path or embedded path set by the ld +b command) and the default directory /usr/lib/hpux64 for 64-bit libraries or the default directory /usr/lib/hpux32 for 32-bit libraries.

For PA-RISC 32-bit compatibility mode libraries (libraries built or linked with ld +compat), the dynamic loader only does 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 works 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 is searched first in compatibility mode. See the +help option to ld(1) or the HP-UX Linker and Libraries User's Guide for more details.

The dynamic loader uses 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 are 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 notices that this information is available, and it uses 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.

Breadth-first Searching

By default, the dynamic loader does 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. (See Depth-first Searching.) Breadth-first searching specifies that the dynamic loader looks 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 is searched, followed by the dependent shared libraries of the second library in the list, and so on.

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.

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, +gstsize, and +nodynhash, 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 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.

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

Dynamic Loader Behavior in PA-RISC 32-bit Compatibility Mode

The dynamic loader maintains certain behaviors to support compatibility with earlier PA-RISC 32-bit releases. These operations apply to programs created with the ld +compat command and the shl_load() library management routines.

The LD_PRELOAD Environment Variable

NOTE: The LD_PRELOAD feature is disabled for seteuid/setegid programs, such as passwd. See ld(1) for more details. This feature is not available to fully-bound static executables.

The LD_PRELOAD environment variable allows you to load additional shared libraries at program startup. LD_PRELOAD provides a colon-separated or space-separated list of shared libraries that the dynamic loader can interpret. The dynamic loader, dld.so, loads the specified shared libraries as if the program had been linked explicitly with the shared libraries in LD_PRELOAD before any other dependents of the program.

At startup time, the dynamic loader implicitly loads one or more libraries, if found, specified in the LD_PRELOAD environment. It uses the same load order and symbol resolution order as if the library had been explicitly linked as the first library in the link line when building the executable. For example, given an executable built with the following link line:

If LD_PRELOAD="/var/tmp/lib1.so", the dynamic loader uses the same load order and symbol resolution order as if lib1.so had been specified as the first library in the link line:

In a typical command line use (with /usr/bin/sh), where LD_PRELOAD is defined as follows:

The dynamic loader searches application according to $PATH, but searches mysl.so according to SHLIB_PATH and/or LD_LIBRARY_PATH, and/or the embedded path (if enabled).

NOTE: Because the dynamic loader checks the LD_PRELOAD environment variable when running any executable (except seteuid/setegid programs), if you export LD_PRELOAD, you should unset it after running your executable, or run the executable as in the command listed above or in a script.

You can use the LD_PRELOAD environment variable to load a shared library built with static thread-local storage model that contains TLS to avoid the following error when loading the library dynamically:

You can use +tls=dynamic compiler option to re-compile the library to avoid the above error message.

The load order and symbol resolution order may be different in a PA-RISC 32-bit compatibility mode program because the dynamic loader uses depth-first search order in PA-RISC 32-bit mode and breadth-first search order in standard mode. See Symbol Searching and Dependent Libraries in the +help option to ld(1) or the HP-UX Linker and Libraries User's Guide for more information.

The dynamic loader uses the LD_PRELOAD environment variable even if you use the +noenvvar in the link line. This insures that LD_PRELOAD is enabled even in a +compat link. The LD_PRELOAD variable is always enabled except for setuid and setgid programs.

Note: Using LD_PRELOAD can cause a core dump when used with applications which mix shared and archived libraries, especially when both the shared library and the application are built with aC++ or use libc.

You can specify multiple libraries as part of the LD_PRELOAD environment variable. Separate the libraries by spaces or colons as in LD_LIBRARY_PATH. (Multi-byte support is not provided as part of parsing the LD_PRELOAD library list). You can specify LD_PRELOAD libraries with absolute paths or relative paths. The LD_PRELOAD libraries can also consist of just the library names, in which case the dynamic loader uses the directory path list in the environment variables LD_LIBRARY_PATH and/or SHLIB_PATH or the embedded path list (if enabled) to search for the libraries.

The dynamic loader does not issue an error or warning message if it cannot find a library specified by LD_PRELOAD. However, if it does not find a dependent of the LD_PRELOAD libraries, the dynamic loader issues the same error message as if the LD_PRELOAD library is specified in the link line.

System Tools

Miscellaneous

Texts and Tutorials