HP-UX Reference (11i v3 07/02) - 5 Miscellaneous Topics (vol 9)

d
dld.sl(5) dld.sl(5)
(PA-RISC System Only)
Library-level Versioning
The second way for users to version their libraries is by using a new naming convention, libname.n where
n is a numeral that is incremented with every new release of the library. When using the new naming
scheme, users must specify an internal name for the shared library by using the
+h internal_name option
to
ld when building the shared library. This internal name is recorded in each incomplete executable or
shared library that links with the shared library.
At run time, the loader will look at the shared library list recorded in the incomplete executable file or
shared library. For each library in the list that was not an internal name, the dynamic loader will look for
a .0 version of the library (e.g.
libname.0) to load. If it does not find this version, it will look for the
library name that is recorded in the list.
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 programmati-
cally. 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 programmati-
cally. 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 partic-
ularly 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 sym-
bols 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 sys-
tems 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 mechan-
ism provide default values of table size, 1103, and number of buckets, 3.
114 Hewlett-Packard Company − 4 − HP-UX 11i Version 3: February 2007