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 PA-RISC 64-bit systems and by specifying the +z/+Z options on PA-RISC 32-bit systems. 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 PA-RISC 32-bit systems, the dynamic loader either calls a thread routine to set the thread pointer and allocate space for the initial thread or calls mmap() and lwp_setprivate() to allocate the space and setup the thread pointer. On PA-RISC 64-bit systems, the dynamic loader invokes 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 PA-RISC 32-bit 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 PA-RISC 32-bit Dynamic Path List and/or PA-RISC 64-bit 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.

PARISC 32-bit 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.

PA-RISC 64-bit 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 the shared 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 dynamic 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 PA-RISC 64-bit systems. 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 shared library list. Then the dependent shared libraries of the first library in the shared library 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 PA-RISC 32-bit systems and is used on PA-RISC 64-bit systems 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 shared library 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 shared library 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.

PA-RISC 32-bit 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.

PA-RISC 64-bit 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. Instead, this mechanism allows the dynamic loader to scan one table which contains the symbol information from all the loaded libraries. 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 export symbols and places them into this table. When a library is unloaded, the mechanism looks up the library's export symbols 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.

The global symbol table mechanism can force the dynamic loader (dld.sl) to perform a large number of hashing operations to locate symbols. Performing this hash function can cost considerable time, especially when symbol names are very long (C++ programs). To speed up the loader, you can off-load computing hash values to the linker by using the +gst option. This causes the linker to compute the hash value for all symbols exported from libraries listed on the link line, and store the hash values in the executable. At run time, the loader then builds the global symbol table in memory and reads the stored hash values from the executable as each library is loaded. If you do not specify +gst at link time, you can use the +gst flag option of the chatr(1) command to enable the global symbol table mechanism, which causes the loader to build the table and compute the hash values at run time.

Use the GST options (with the ld and chatr commands), +gst, +gstbuckets (PA-RISC 32-bit only), +gstsize, +nodynhash (PA-RISC 64-bit systems only), and +plabel_cache, (PA-RISC 32-bit systems only) to control the behavior of the global symbol table hash mechanism. You can use the +gstsize and +nodynhash linker/chatr options to control the behavior of the global symbol table hash mechanism. With the GST 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 provides a message for each library that contains the following information:

See the ld(1) and chatr(1) commands for information on the +gst, +gstbuckets, +gstsize, +nodynhash, and +plabel_cache options.

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.sl, loads the specified shared liraries 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.sl", the dynamic loader uses the same load order and symbol resolution order as if lib1.sl had been specified as the first library in the link line:

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

The dynamic loader searches application according to $PATH, but searches mysl.sl 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 that contains thread-local storage to avoid the following error when loading the library dynamically:

The load order and symbol resolution order may be different in a PA-RISC 32-bit program than in the same PA-RISC 64-bit program because the dynamic loader uses depth-first search order in PA-Risc 32-bit mode and breadth-first search order in PA-RISC 64-bit 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: If an archive library is already linked-in with the application and we try to load the shared version of that library using LD_PRELOAD we will have problems.

The potential problems are :

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.

The LD_PRELOAD_ONCE Environment Variable

The LD_PRELOAD_ONCE feature is similar to LD_PRELOAD except that the dynamic loader, dld.sl, unsets LD_PRELOAD_ONCE after reading it, so that any applications invoked by the current application do not have LD_PRELOAD_ONCE set. This is useful in situations where the current application needs certain libraries preloaded while the child application is adversely affected if these are preloaded (for example, ksh terminates abnormally if LD_PRELOAD contains /usr/lib/libpthread.1). The libraries specified by LD_PRELOAD_ONCE are loaded before the ones specified by LD_PRELOAD. The effect on symbol resolution is that the symbols from libraries specified by LD_PRELOAD_ONCE take precedence over symbols from libraries specified by LD_PRELOAD.

System Tools

Miscellaneous

Texts and Tutorials