dlsym - get the address of a symbol in a shared object or executable
#include <dlfcn.h> void *dlsym(void *restrict handle, const char *restrict name);
The dlsym() function allows a process to obtain the address of a symbol that is defined within a shared object or executable. The handle argument is either the value returned from a call to dlopen(), or one of a family of special handles. The name argument is the symbol's name as a character string.
If handle is returned from dlopen(), the associated shared object must not have been closed using dlclose(). A handle can be obtained from dlopen() using the RTLD_FIRST mode. With this mode, the dlsym() function searches for the named symbol in the initial object referenced by handle. Without this mode, the dlsym() function searches for the named symbol in the group of shared objects loaded automatically as a result of loading the object referenced by handle. See dlopen(3C) and NOTES.
Dynamic objects can be built to employ lazy loading. This model provides for loading dependencies only when a reference to the dependency is made. See the –z lazyload option of ld(1). Lazy loading is optimal when every dynamic object within a process explicitly defines all of their required dependencies. However, dlsym() attempts to compensate for objects that have not fully defined their dependencies when lazy loading is employed. If a symbol can not be found in any presently loaded objects, any pending lazy loadable dependencies of those objects are processed in an attempt to locate the symbol. This compensation undermines the advantages of lazy loading by causing unnecessary objects to be loaded in an attempt to locate the symbol. Such objects should be rebuilt to define all of their required dependencies.
The following special handles are supported.
Instructs dlsym() to search for the named symbol using the default search mechanism that is used to resolve symbol references for all objects within a process. Objects are searched in the order that they were loaded in the process. This search starts with the first object loaded, typically the dynamic executable. The search continues through the initial global dependencies that were loaded with the process, and any objects loaded through dlopen(3C). See also NOTES.
Instructs dlsym() to search for the named symbol in the same manner as occurs with a handle of RTLD_DEFAULT. However, RTLD_PROBE only searches for symbol definitions in any presently loaded objects to provide the named symbol. RTLD_PROBE does not otherwise load any objects. This handle can provide a more optimal search than would occur using RTLD_DEFAULT. See also NOTES.
Instructs dlsym() to search for the named symbol in the same manner as occurs with a handle of RTLD_DEFAULT, but starting from the objects that are loaded following the object from which the dlsym() call originates.
Instructs dlsym() to search for the named symbol in the same manner as occurs with a handle of RTLD_DEFAULT, but starting from the object from which the dlsym() call originates.
When used with a special handle, dlsym() is selective in searching objects that were loaded using dlopen(). These objects are searched for symbols if one of the following conditions are true.
The object is part of the same local dlopen() dependency hierarchy as the calling object.
The object has global search access. See dlopen(3C) for a discussion of the RTLD_GLOBAL mode.
If the object from which the dlsym() originates makes reference to the same symbol, other than from dlsym() use, then a dependency may exist that is expected to provide the symbol definition. In this case, dlsym() ensures this dependency is loaded before carrying out the symbol search. Thus, in the case of RTLD_PROBE, a specific dependency of the originating object can be lazily loaded to provide for finding the required symbol.
The dlsym() function returns NULL if handle does not refer to a valid object opened by dlopen() or is not one of the special handles. The function also returns NULL if the named symbol cannot be found within any of the objects associated with handle. Additional diagnostic information is available through dlerror(3C).
The following code fragment demonstrates how to use dlopen() and dlsym() to access a function and a data item. For simplicity, error checking has been omitted.
void *handle;
int *iptr, (*fptr)(int);
/* open the needed object */
handle = dlopen("/usr/home/me/libfoo.so.1", RTLD_LAZY);
/* find the address of the function and data item */
fptr = (int (*)(int))dlsym(handle, "my_function");
iptr = (int *)dlsym(handle, "my_object");
/* invoke the function, with the data item as a parameter */
(*fptr)(*iptr);
Example 2 Use dlsym() to verify that a particular function is defined.
The following code fragment shows how to use dlsym() to verify that a function is defined within the process. If the function exists, the function is called.
int (*fptr)();
if ((fptr = (int (*)())dlsym(RTLD_DEFAULT,
"my_function")) != NULL) {
(*fptr)();
}
The dlsym() function is one of a family of functions that give the user direct access to the dynamic linking facilities. These facilities are available to dynamically-linked processes only. See the Oracle Solaris 11.4 Linkers and Libraries Guide.
See attributes(7) for descriptions of the following attributes:
|
ld(1), ld.so.1(1), dladdr(3C), dlclose(3C), dldump(3C), dlerror(3C), dlinfo(3C), dlopen(3C), attributes(7), standards(7)
Oracle Solaris 11.4 Linkers and Libraries Guide
If an object is acting as a filter, care should be taken when interpreting the address of any symbol obtained using a handle to this object. For example, using dlsym(3C) to obtain the symbol _end for this object, results in returning the address of the symbol _end within the filtee, not the filter. For more information on filters see Shared Objects as Filters in Oracle Solaris 11.4 Linkers and Libraries Guide.
In very specialized cases, an object can be built to bind symbol references to definitions that are available within the same object. See the –B symbolic option of ld(1). If a dlsym() request, using RTLD_DEFAULT or RTLD_PROBE, originates from a symbolic object, the dlsym() search inspects the symbolic object first, before continuing with the search associated with the handle.