HP-UX Reference (11i v3 07/02) - 3 Library Functions A-M (vol 6)

d
dlopen_pa(3C) dlopen_pa(3C)
(HP 9000 Systems Only)
To determine the scope of symbols that are made available for relocation processing of objects loaded in a
dlopen() invocation, the mode parameter can be bitwise or’ed with one of the following values:
RTLD_GROUP Under this mode, the specified object, and its dependencies, behave as if they were
built with -B group (see ld(1)). Only symbols from objects loaded in the same
dlopen() invocation are made available for relocation. This ensures that all reloca-
tions are satisfied using symbol definitions from the same
dlopen() invocation.
RTLD_WORLD Under this mode, only symbols from global objects and from the object itself are avail-
able for relocation processing. It does not use symbol definitions from other objects
loaded as part of the dlopen() invocation. This flag has no effect on objects build
with -B group (see ld(1)).
RTLD_PARENT Under this mode, symbols from the object that invoked
dlopen() are also made
available for relocation.
The modes
RTLD_GROUP , RTLD_WORLD , and RTLD_PARENT
are presently supported only for 64-bit
applications.
The default modes for
dlopen() are RTLD_WORLD
|RTLD_GROUP. These flags are OR’ed together
when the same object is loaded with different modes.
The following flags do not affect relocation processing but provide other features:
RTLD_NODELETE Under this mode, the specified object and its dependencies behave as if they were
built with
-B nodelete (see ld(1)). An explicit unload using dlclose() or
shl_load() returns success silently without detaching the shared library from the
process. Subsequently, the shared library handle is valid only for
shl_findsym().
It stays invalid for
dlsym(), dlclose(), and shl_unload() until the next
explicit load using shl_load() or dlclose().
RTLD_NOLOAD Under this mode, the specified object is not loaded into the process’s address space,
but a valid handle is returned if the object already exists in the process address space.
If the specified object does not already exist, then an error is returned.
RTLD_NOLOAD can be used to query the presence, or for overriding the modes, of an
existing object.
Symbols introduced into a program through calls to dlopen() may be used in relocation activities. Sym-
bols so introduced may duplicate symbols already defined by the program or previous dlopen() opera-
tions. To resolve the ambiguities such a situation might present, the resolution of a symbol reference to a
symbol definition is based on a symbol resolution order. Two such resolution orders are defined: load and
dependency ordering. Load order establishes an ordering among symbol definitions using the temporal
order in which the objects containing the definitions were loaded, such that the definition first loaded has
priority over definitions added later. Load ordering is used in relocation processing. Dependency ordering
uses a "breadth-first" order starting with a given object, then all of its dependencies, then any dependents
of those, iterating until all dependencies are satisfied. With the exception of the global symbol object
obtained via a
dlopen() operation on a file with a value 0, dependency ordering is used by the
dlsym()
function. Load ordering is used in dlsym() operations on the global symbol object.
When an object is first made accessible via dlopen(), it and its dependent objects are added in depen-
dency order. Once all objects are added, relocations are performed using load order. Note that if an object
and its dependencies have been loaded by a previous dlopen() invocation or on startup, the load and
dependency order may yield different resolutions.
The symbols introduced by dlopen() operations and available through dlsym() are those which are
"exported" as symbols of global scope by the object. For shared objects, such symbols are typically those
that were specified in (for example) C source code as having extern linkage. For a.out’s, only a subset of
externally visible symbols are typically exported: specifically those referenced by the shared objects with
which the a.out is linked. The exact set of exported symbols for any shared object or the a.out can be
controlled using the linker (see ld(1)).
HP 9000 64-bit dlopene()
The dlopen_opts structure has the following members:
struct dlopen_opts {
long flags;
char* text_addr;
char* data_addr;
HP-UX 11i Version 3: February 2007 − 3 − Hewlett-Packard Company 313