dlopen_ia.3c (2010 09)

d
dlopen_ia(3C) dlopen_ia(3C)
(Integrity Systems Only)
an existing object.
Symbols introduced into a program through calls to
dlopen() may be used in relocation activities.
Symbols so introduced may duplicate symbols already defined by the program or previous
dlopen()
operations. To resolve the ambiguities such a situation might present, the resolution of a symbol refer-
ence 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 pro-
vided.
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:
• READ, WRITE and EXECUTE (RWX) permission for text_addr .
• READ and WRITE (RW) permission for data_addr .
HP-UX 11i Version 3: September 2010 − 3 − Hewlett-Packard Company 3