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

d
dlopen_ia(3C) dlopen_ia(3C)
(Integrity Systems Only)
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 glo-
bal 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)).
The dlopen_opts structure has the following members:
struct dlopen_opts {
long flags;
char* text_addr;
char* data_addr;
};
flags contains the load option, defined by logical OR of the following values:
RTLD_EXT_TEXT_ADDR
Indicates that an explicit base address for the shared library text segment is provided.
RTLD_EXT_DATA_ADDR
Indicates that an explicit base address for the shared library private data segment is
provided.
RTLD_EXT_DATA_NO_ZERO_FILL
If this flag is set, dlopene() does not zero fill the bss part of the data segment.
This may improve load time for libraries with large bss sections. This flag is only valid
with RTLD_EXT_DATA_ADDR.
The dynamic loader only accesses the address fields that are specified by the flags fields.
text_addr contains the explicit base address for the shared library’s text segment.
data_addr contains the explicit base address for the shared library’s data segment.
Both the text_addr and data_addr must be aligned at a 16-byte boundary.
The caller can invoke dlgetfileinfo() to obtain the information needed to allocate memory for the
load segments.
The caller of dlopene() is responsible for allocating memory with the appropriate permission:
HP-UX 11i Version 2: December 2007 Update − 3 − Hewlett-Packard Company 315