|DLOPEN(3C)||Standard C Library Functions||DLOPEN(3C)|
#include <dlfcn.h> #include <link.h> void *dlopen(const char *pathname, int mode);
void *dlmopen(Lmid_t lmid, const char *pathname, int mode);
The dlopen() function also loads any dependencies recorded within pathname. These dependencies are searched in the order in which the dependencies were loaded to locate any additional dependencies. This process continues until all the dependencies of pathname are loaded. This dependency tree is referred to as a group.
If the value of pathname is 0, dlopen() provides a handle on a set of global symbol objects. These objects consist of the original program image file, any dependencies loaded at program startup, and any objects loaded using dlopen() with the RTLD_GLOBAL flag. Because the latter set of objects can change during process execution, the set identified by handle can also change dynamically.
The mode argument describes how dlopen() operates on pathname with respect to the processing of reference relocations. The mode also affects the scope of visibility of the symbols provided by pathname and its dependencies. This visibility can affect how the resulting handle is used.
When an object is loaded, the object can contain references to symbols whose addresses are not known until the object is loaded. These references must be relocated before the symbols can be accessed. References are categorized as either immediate or lazy. Immediate references are typically references to data items used by the object code. Immediate references include pointers to functions and calls to functions made from position-dependent shared objects. Lazy references are typically calls to global functions that are made from position-independent shared objects. The mode argument governs when these references take place. The mode argument can be one of the following values:
See the Linker and Libraries Guide for more information about symbol references.
The visibility of symbols that are available for relocation can be affected by mode. To specify the scope of visibility for symbols that are loaded with a dlopen() call, mode should be a bitwise-inclusive OR with one of the following values:
The program image file and any objects loaded at program startup have the mode RTLD_GLOBAL. The mode RTLD_LOCAL is the default mode for any objects that are acquired with dlopen(). A local object can be a dependency of more than one group. Any object of mode RTLD_LOCAL that is referenced as a dependency of an object of mode RTLD_GLOBAL is promoted to RTLD_GLOBAL. In other words, the RTLD_LOCAL mode is ignored.
Any object loaded by dlopen() that requires relocations against global symbols can reference the symbols in any RTLD_GLOBAL object. Objects of this mode are at least the program image file and any objects loaded at program startup. A loaded object can also reference symbols from itself, and from any dependencies the object references. However, the mode parameter can also be a bitwise-inclusive OR with one of the following values to affect the scope of symbol availability:
The default modes for dlopen() are both RTLD_WORLD and RTLD_GROUP. If an object is requires additional modes, the mode parameter can be the bitwise-inclusive OR of the required modes together with the default modes.
The following modes provide additional capabilities outside of relocation processing:
The default use of a handle with dlsym() allows a symbol search to inspect all objects that are associated with the group of objects that are loaded from dlopen(). The mode parameter can also be a bitwise-inclusive OR with the following value to restrict this symbol search:
An object can be accessed from a process both with and without RTLD_FIRST. Although the object will only be loaded once, two different handles are created to provide for the different dlsym() requirements.
The dlmopen() function is identical to dlopen(), except that an identifying link-map ID (lmid) is provided. This link-map ID informs the dynamic linking facilities upon which link-map list to load the object. See the Linker and Libraries Guide for details about link-maps.
The lmid passed to dlmopen() identifies the link-map list on which the object is loaded. This parameter can be any valid Lmid_t returned by dlinfo() or one of the following special values:
|ATTRIBUTE TYPE||ATTRIBUTE VALUE|
Linker and Libraries Guide
When loading shared objects, the application should open a specific version of the shared object. Do not rely on the version of the shared object pointed to by the symbolic link.
When building objects to be loaded on a new link-map list, some precautions need to be taken. In general, all dependencies must be included when building an object. Also, include /usr/lib/libmapmalloc.so.1 before /lib/libc.so.1 when building an object.
When an object is loaded on a new link-map list, the object is isolated from the main running program. Certain global resources are only usable from one link-map list. A few examples are the sbrk() based malloc(), libthread(), and the signal vectors. Care must be taken not to use any of these resources other than from the primary link-map list. These issues are discussed in further detail in the Linker and Libraries Guide.
Some symbols defined in dynamic executables or shared objects can not be available to the runtime linker. The symbol table created by ld for use by the runtime linker might contain only a subset of the symbols that are defined in the object.
As part of loading a new object, initialization code within the object is called before the dlopen() returns. This initialization is user code, and as such, can produce errors that can not be caught by dlopen(). For example, an object loaded using RTLD_LAZY that attempts to call a function that can not be located results in process termination. Erroneous programming practices within the initialization code can also result in process termination. The runtime linkers debugging facility can offer help identifying these types of error. See the LD_DEBUG environment variable of ld.so.1(1).
Loading relocatable objects is an expensive operation that requires converting the relocatable object into a shared object memory image. This capability may be useful in a debugging environment, but is not recommended for production software.
|May 16, 2020||OmniOS|