dld.so(5) dld.so(5)
Itanium(R)-based System Only
NAME [Toc] [Back]
dld.so - dynamic loader
MULTITHREAD USAGE [Toc] [Back]
The dynamic loader is thread-safe.
DESCRIPTION [Toc] [Back]
The /usr/lib/hpux64/dld.so shared library is the 64-bit dynamic
loader. The /usr/lib/hpux32/dld.so shared library is the 32-bit
dynamic loader. In programs that use shared libraries, dld.so is
invoked automatically at startup time. /usr/ccs/lib/hpux64/crt0.o is
the 64-bit run-time startup file. /usr/ccs/lib/hpux32/crt0.o is the
32-bit run-time startup file. The /usr/lib/hpux32/uld.so and
/usr/lib/hpux64/uld.so shared libraries are the 32-bit and 64-bit
microloaders. In programs that use shared libraries, the microloader
is invoked automatically at startup time by exec(2). The
microloader's sole responsibility is to load the dynamic loader,
dld.so, into memory for program execution. The microloaders (uld.so)
and the dynamic loaders (dld.so) are, themselves, shared libraries,
although they define no symbols for use by user programs.
Shared Libraries [Toc] [Back]
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 [Toc] [Back]
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 [Toc] [Back]
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:
/usr/lib/hpux[32|64]/dld.so: Can't shl_load() a library containing
Thread Local Storage: /usr/lib/hpux[32|64]/libcps.so.1
Hewlett-Packard Company - 1 - HP-UX 11i Version 2: Sep 2004
dld.so(5) dld.so(5)
Itanium(R)-based System Only
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 [Toc] [Back]
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 [Toc] [Back]
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:
+ ld +s
+ ld +b
+ chatr +s enable
There are several ways to specify a dynamic path list :
+ By storing a directory path list in the executable (in rpath) using
the +b path_list option to ld.
Hewlett-Packard Company - 2 - HP-UX 11i Version 2: Sep 2004
dld.so(5) dld.so(5)
Itanium(R)-based System Only
+ By not specifying ld +b and letting the linker set the rpath value
to a concatenation of the ld -L path_list followed by the value of
the environment variable LPATH followed by the 64-bit default
directory /usr/lib/hpux64, or the 32-bit default directory
/usr/lib/hpux32.
+ By storing a directory path list in the environment variables
LD_LIBRARY_PATH and/or SHLIB_PATH. LD_LIBRARY_PATH and SHLIB_PATH
can contain paths for both 32 and 64 bit libraries; dld.so will
only load appropriate libraries. For compatibility mode shared
libraries and executables, the directory path list should only be
put in the SHLIB_PATH environment variable.
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:
+ If ld +noenvvar was specified and ld +b and ld +compat were not
specified, then the only dynamic path searching that can be done is
to look at the path list in rpath followed by the 64-bit default
directory /usr/lib/hpux64, or the 32-bit default directory
/usr/lib/hpux32.
+ If ld +compat was specified and ld +b and ld +s were not specified,
no shared library is subject to dynamic path searching. The linktime
location of the library (recorded path) is used.
+ If the ld +compat and ld +b options are not specified, then the
path list in the LD_LIBRARY_PATH environment variable is searched,
followed by the path list in the SHLIB_PATH environment variable,
followed by the path list in rpath, followed by the 64-bit default
directory /usr/lib/hpux64, or the 32-bit default directory
/usr/lib/hpux32.
+ If the ld +compat, ld +b, and ld +s are specified, then use the
relative ordering of ld +b and ld +s to determine if the dynamic
loader should use the path list in rpath before SHLIB_PATH followed
by library as specified in the library list. If ld +b is specified
first, use the path list in rpath first.
The rules change slightly when looking for dependent shared libraries.
Hewlett-Packard Company - 3 - HP-UX 11i Version 2: Sep 2004
dld.so(5) dld.so(5)
Itanium(R)-based System Only
+ For default mode libraries, the path list in the LD_LIBRARY_PATH
environment variable is searched first, followed by the path list
in the SHLIB_PATH environment variable, followed by the value in
the parent shared library's rpath, followed by the 64-bit default
directory /usr/lib/hpux64, or the 32-bit default directory
/usr/lib/hpux32. The ancestors of a parent shared library may
contain a path list in rpath, but this is ignored when searching
for dependent shared libraries of this parent. Only the parent's
rpath is used.
+ For compatibility mode libraries, the search is the same as for
parent shared libraries, except rpath can be passed from parent
shared libraries to child dependent shared libraries to that
child's dependents, and so on.
Binding [Toc] [Back]
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 [Toc] [Back]
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.
Hewlett-Packard Company - 4 - HP-UX 11i Version 2: Sep 2004
dld.so(5) dld.so(5)
Itanium(R)-based System Only
Version Control [Toc] [Back]
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.
Library-level Versioning [Toc] [Back]
Users can control versions of their libraries by using a 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 looks at the 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 looks for a .0
version of the library (for example, libname.0) to load. If it does
not find this version, it looks for the library name that is recorded
in the list.
Explicit Loading and Binding [Toc] [Back]
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 [Toc] [Back]
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.
Hewlett-Packard Company - 5 - HP-UX 11i Version 2: Sep 2004
dld.so(5) dld.so(5)
Itanium(R)-based System Only
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:
+ Operation (load/unload)
+ Name of library
+ Number of exports
+ Number of entries in table with no stored symbols
+ Average length of non-zero chains
+ Calculated performance of the hash table
+ Amount of memory used by the hash table
Dynamic Loader Behavior in PA-RISC 32-bit Compatibility Mode [Toc] [Back]
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.
Dynamic Path List [Toc] [Back]
There are two ways to specify a dynamic path list :
+ by storing a directory path list in the executable using the +b
path_list option to ld,
Hewlett-Packard Company - 6 - HP-UX 11i Version 2: Sep 2004
dld.so(5) dld.so(5)
Itanium(R)-based System Only
+ by linking the executable with ld option +s, enabling the
executable to use the path list defined by the SHLIB_PATH
environment variable at run time.
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.
Depth-first Searching [Toc] [Back]
This is the search behavior used by the compatibility mode, and is
used if doing a shl_load() or if the incomplete executable was linked
with +compat. The dynamic loader searches 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, and so on.
Diagnostics and Warnings [Toc] [Back]
In compatibility mode, if you wish to see all of the messages, set the
environment variable _HP_DLDOPTS to contain one or more options. The
following options are supported:
-warnings Display additional dynamic loader warning
messages. Some of these include:
+ Symbols of the same name but different types,
such as CODE and DATA. See the WARNINGS
section in ld(1) for more details on this
warning.
+ Using certain flags or routines described in
shl_load(3X).
-fbverbose See fastbind(1).
-nofastbind See fastbind(1).
The LD_PRELOAD Environment Variable [Toc] [Back]
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
Hewlett-Packard Company - 7 - HP-UX 11i Version 2: Sep 2004
dld.so(5) dld.so(5)
Itanium(R)-based System Only
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:
$ ld ... lib2.so lib3.so lib4.so
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:
$ ld ... /var/tmp/lib1.so lib2.so lib3.so lib4.so
In a typical command line use (with /usr/bin/sh), where LD_PRELOAD is
defined as follows:
$ LD_PRELOAD=mysl.so application
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:
/usr/lib/hpux[32|64]/dld.so: Can't shl_load() a library containing
Thread Local Storage: /usr/lib/hpux[32|64]/libcps.so.1
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 PARISC
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
Hewlett-Packard Company - 8 - HP-UX 11i Version 2: Sep 2004
dld.so(5) dld.so(5)
Itanium(R)-based System Only
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.
DIAGNOSTICS [Toc] [Back]
If the dynamic loader is not present, or cannot be invoked by the
process for any reason, an error message is printed to standard error
and the process terminates with a non-zero exit code.
These errors fall into two basic categories: errors in attaching a
shared library, and errors in binding symbols. The former can occur
only at process startup time but the latter can occur at any time
during process execution unless the -B immediate option is used with
ld. Possible errors that can occur while attaching a shared library
include library not present, library not executable, library corrupt,
high water mark too low, or insufficient room in the address space for
the library. Possible errors that can occur while binding symbols
include symbol not found (unresolved external), or library corrupt.
When using the explicit load facilities of the dynamic loader, these
types of errors are not considered fatal. Consult shl_load(3X),
dlclose(3C), dlget(3C), dlgetname(3C), dlmodinfo(3C), dlopen(3C), and
dlsym(3C) for more information. To see error messages, use the
dlerror() routine. This routine prints the last error message
recorded by the dynamic loader.
Hewlett-Packard Company - 9 - HP-UX 11i Version 2: Sep 2004
dld.so(5) dld.so(5)
Itanium(R)-based System Only
WARNINGS [Toc] [Back]
The startup cost of the dynamic loader is significant, even with
deferred binding, and can cause severe performance degradation in
processes dominated by startup costs (such as simple ``hello world''
programs). In addition, position-independent code is usually slower
than normal code, so performance of a program may be adversely
affected by the presence of PIC in shared libraries. However, the
advantages of decreased disk space usage and decreased memory
requirements for executables should outweigh these concerns in most
cases.
There are rare cases where the behavior of a program differs when
using shared libraries as opposed to archive libraries. This happens
primarily when relying on undocumented and unsupported features of the
compilers, assembler, and linker. See the +help option to ld(1) or
the HP-UX Linker and Libraries User's Guide for more details.
The library developer is entirely responsible for version control and
must be thorough in identifying incompatible changes to library
interfaces. Otherwise, programs may malfunction unexpectedly with
later versions of the library. There is little an application user
can do if version control is not handled properly by the library
developer. The application developer can usually resolve problems by
modifying the source code to use the new interfaces then recompiling
and relinking against the new libraries.
By default, most warnings are not reported by the dynamic loader. If
you wish to see all error messages, set the environment variable
DLD_VERBOSE_ERR to true.
AUTHOR [Toc] [Back]
The /usr/lib/hpux64/dld.so and /usr/lib/hpux32/dld.so shared libraries
were developed by HP.
SEE ALSO [Toc] [Back]
System Tools
aCC(1) invoke the HP-UX aC++ compiler
as(1) translate assembly code to machine code
cc(1) invoke the HP-UX C compiler
chatr(1) change program's internal attributes
f90(1) invoke the HP-UX Fortran 90 compiler
fastbind(1) invoke the fastbind tool
ld(1) invoke the link editor
Miscellaneous [Toc] [Back]
a.out(4) assembler, compiler, and linker output
dlclose(3C) unload a shared library previously loaded by
dlopen()
dlerror(3C) print the last error message recorded by dld
dlget(3C) return information about a loaded module
Hewlett-Packard Company - 10 - HP-UX 11i Version 2: Sep 2004
dld.so(5) dld.so(5)
Itanium(R)-based System Only
dlgetname(3C) return the name of the storage containing a load
module
dlmodinfo(3C) return information about a loaded module
dlopen(3C) load a shared library
dlsym(3C) get the address of a symbol in a shared library
shl_load(3X) load/unload shared libraries
Texts and Tutorials [Toc] [Back]
HP-UX Linker and Libraries Online User Guide
(See the +help option to ld(1))
HP-UX Linker and Libraries User's Guide
(See manuals(5) for ordering information)
Hewlett-Packard Company - 11 - HP-UX 11i Version 2: Sep 2004 [ Back ] |
