svcadm(1M)을 검색하려면 섹션에서 1M 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
dlsym(3c)
Standard C Library Functions dlsym(3C)
NAME
dlsym - get the address of a symbol in a shared object or executable
SYNOPSIS
#include <dlfcn.h>
void *dlsym(void *restrict handle, const char *restrict name);
DESCRIPTION
The dlsym() function allows a process to obtain the address of a symbol
that is defined within a shared object or executable. The handle argu‐
ment 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() func‐
tion 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 pro‐
vides 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.
RTLD_DEFAULT
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 contin‐
ues through the initial global dependencies that were loaded with
the process, and any objects loaded through dlopen(3C). See also
NOTES.
RTLD_PROBE
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.
RTLD_NEXT
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.
RTLD_SELF
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.
o The object is part of the same local dlopen() dependency
hierarchy as the calling object.
o 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 sym‐
bol 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.
RETURN VALUES
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 infor‐
mation is available through dlerror(3C).
EXAMPLES
Example 1 Use dlopen() and dlsym() to access a function and a data
item.
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)();
}
USAGE
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.
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
TRIBUTE VALUE _ Interface StabilityCommitted _ MT-LevelMT-Safe _ Stan‐
dardSee standards(7).
SEE ALSO
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
NOTES
If an object is acting as a filter, care should be taken when inter‐
preting 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 refer‐
ences 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.
Oracle Solaris 11.4 29 December 2014 dlsym(3C)