svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
kldd(1)
kldd(1) User Commands kldd(1)
NAME
kldd - list dependencies of kernel modules
SYNOPSIS
kldd [-bcmprsuUvVw] [-D CPU=cpuname] [-k file | -K] [-P platform,...]
[-R path] [-S path] file...
DESCRIPTION
The kldd utility lists the dependencies of kernel modules. kldd emu‐
lates the behavior of the kernel runtime linker, krtld, to generate the
diagnostics.
By default, kldd examines all kernel module dependencies that are asso‐
ciated with the file being inspected, followed by the unix kernel, and
any dependencies of the kernel.
In its simplest form, kldd analyzes the dependency requirements of the
objects being inspected. kldd can also be instructed to analyze the re‐
location requirements of each object, which result in binding symbol
references to symbol definitions.
OPTIONS
The following options are supported:
-b
Report symbol binding.
-c
Display any common (tentative) symbols encountered in the objects
being inspected.
-D CPU=cpuname
Change the expansion of $CPU tokens in dependency names from the
default of generic to the string given by cpuname. See NOTES.
-k file
Specify the unix kernel to be used. By default, kldd will use the
default kernel.
-K
Limit processing to the objects being inspected, and their depen‐
dencies. Do not inspect the kernel, or dependencies of the kernel.
-m
Display any multiply defined symbols encountered in the objects be‐
ing inspected.
-p
Display any unresolved explicit parent or external references. See
External Interfaces under USAGE.
-P platform,...
Specify platform directories to be used when searching for kernel
modules and the unix kernel. By default, kldd uses the platform of
the running system. The -P option can be used to replace this de‐
fault with one or more platform directories, to be searched in the
order specified. Platforms are specified as a comma separated list
of platform names. For example: -Pi86pc,i86hvm might be used on an
x86 system to analyze certain kernel modules that require both
platforms. See Kernel Module Search Path under USAGE.
-r
Check references. See Interface Verification under USAGE.
-R path
A colon-separated list of directories to search for kernel modules.
Directories specified with -R are searched ahead of the default
module path. See Kernel Module Search Path under USAGE.
-s
Displays the search path used to locate kernel module dependencies.
-S path
Specify system root (sysroot) directories to be used when searching
for kernel modules and the unix kernel. By default, kldd uses the
system root directory / for this purpose. The -S option can be used
to replace this default with one or more sysroot directories to be
searched in the given order, or to entirely disable sysroot search‐
ing. Set path to a colon separated list of sysroot directories, to
be searched in the order specified. Alternatively, set path to an
empty string, '', to entirely disable sysroot searching. In this
later case, the -R and -k options must be used to supply search
paths and a kernel for kldd to use. See Kernel Module Search Path
under USAGE.
-u
Displays any unused objects. If the -s is specified in conjunction
with -u, used dependencies are also displayed. See Unused Material
under USAGE.
-U
Displays any unreferenced, or unused dependencies. If an unrefer‐
enced dependency is not bound to by other objects loaded with file,
the dependency is flagged as unused. If the -s is specified in con‐
junction with -U, referenced dependencies are also displayed. The
-U is a superset of of -u. See Unused Material under USAGE.
-v
Displays all dependency relationships incurred when processing
file. This option also displays any dependency version require‐
ments. See pvs(1).
-V
--version
Print version information and immediately exit.
-w
Display any unresolved weak symbol references. See Weak References
under USAGE.
Display any weak symbol definitions. Unlike their behavior in non-
kernel objects, weak definitions have no special meaning in kernel
modules. The kernel runtime linker treats weak definitions identi‐
cally to normal global definitions.
-?
--help
Print usage message and immediately exit.
OPERANDS
The following operand is supported:
file
The name of the specified kernel module. If file specifies an ex‐
isting file, that file is opened and analyzed.
If the given file does not exist, and contains at most one slash
(/) character, it is interpreted as the soname of a kernel module.
The kernel module search path is searched for a kernel module
matching the given soname, and if such a module is found, that file
is opened and analyzed.
USAGE
External Interfaces
A kernel module can make reference to symbols that should be supplied
externally to the module. These references can be explicitly classified
when the kernel module is created, as being available from the unix
kernel or a dependency of the unix kernel (parent), or simply as being
external. See the -M mapfile option of ld(1), and the PARENT and EX‐
TERN symbol definition keywords.
When examining a kernel module, a dependency reference to a parent that
cannot be resolved is flagged as an error. A dependency reference to an
external is not flagged as an error.
The -p option causes any unresolved parent or external reference to be
flagged as an error.
Interface Verification
kldd can check the compatibility of symbol references and symbol defin‐
itions for the objects being inspected. With the -r option, kldd prints
warnings for any unresolved symbol references that can occur when file
is loaded.
Unused Material
kldd can validate dependency use. Only when a symbol reference is bound
to a dependency, is that dependency deemed used. With the -U option and
the -u option, kldd prints warnings for any unreferenced, or unused de‐
pendencies that are loaded when file is loaded. These options are use‐
ful when symbol references are being checked.
A dependency that is defined by an object but is not bound to from that
object is an unreferenced dependency. A dependency that is not bound to
by any other object when file is loaded is an unused object.
Dependencies can be located in default system locations used by the
kernel runtime loader, krtld, or in locations specified with the -R op‐
tion.
Objects that are found to be unreferenced, or unused, should be removed
as dependencies. These objects provide no references, but result in un‐
necessary overhead when file is loaded.
The removal of unused dependencies reduces system runtime overhead. The
removal of unreferenced dependencies reduces system runtime overhead to
a lesser degree. However, the removal of unreferenced dependencies
guards against a dependency being unused when combined with different
objects, or as the other object dependencies evolve.
Weak References
Symbols that are used by relocations may be defined as weak references.
By default, if a weak symbol reference can not be resolved, the reloca‐
tion is ignored and a zero written to the relocation offset. The -w op‐
tion, causes any unresolved relocation against a weak symbol reference
to be flagged as a relocation error.
Kernel Module Search Path
To locate kernel modules, kldd constructs a list of directories to
search. Searching consists of checking each directory in this list in
turn, stopping at the first one that provides the desired module. This
mimics the behavior of the kernel runtime linker, and is designed to
yield the same results. kldd displays this search list as part of the
information produced when the -s option is specified.
Directories specified with the -R option are placed at the head of the
list, in the order specified on the command line. Following that, kldd
adds default system defined locations, based on the module search path
constructed by the kernel at boot time. This module search path can
differ in minor details between system. On a typical sparc system, it
appears as follows.
$ kldd -s genunix | egrep 'search|unix =>'
search path=/platform/sun4v/kernel:/kernel:/usr/kernel (default)
unix => /platform/sun4v/kernel/sparcv9/unix
/kernel and /usr/kernel are always present. In addition, there is al‐
ways at least one /platform directory, providing support for the spe‐
cific system hardware, and one of these platform directories provides
the unix kernel. There may be additional platform directories, depend‐
ing on the needs of the specific system. By default, kldd adds the di‐
rectories from the kernel module search path without modification. The
-P and -S options are available to alter this default, allowing kldd to
analyze objects not intended for the running system.
The -P option causes kldd to replace any /platform directories supplied
by the kernel module list with the platform directories specified by
-P. This allows for the analysis of objects intended for use on a dif‐
ferent platform than the running system. See EXAMPLES.
The -S option is used to specify that the default directories should be
interpreted relative to a set of user supplied system root directories,
rather than against /, the root of the currently running system. This
is useful when testing a complete set of new modules together, indepen‐
dent of the running system. This can be used to analyze kernel modules
from a different platform than the currently running system. For each
specified sysroot, in the order given, all the default directories are
added to the search list, prepended with the specified sysroot. Alter‐
natively, the -S option can specify an empty string, '', for the system
root. In this case, the effect is to entirely disable the use of the
default search path. In this mode, the -R option must be used to spec‐
ify directories for kldd to search, and the -k option may be necessary
to specify a unix kernel to analyze. See EXAMPLES.
Kernel modules specify dependencies on other kernel modules using a
simple string referred to as an soname. An soname can have one of 2
forms. The first form gives a plain module name, such as genunix. The
second, more common, form uses a slash delimiter to specify a module
class as well as a module name, such as sys/doorfs). The soname is not
a file path, and cannot be used directly to locate a referenced kernel
module. Instead, the search list is used to look for a module matching
the soname.
Before searching, the kernel rewrites the given soname to insert the
name of the system platform between the class and name parts of the
soname. For example, given an soname of sys/doorfs, the kernel will
transform this into sys/platform/doorfs, where platform is one of amd64
or sparcv9, depending on the system. For example, on a sparc system,
and assuming a default search path of /kernel:/usr/kernel, krtld will
look for /kernel/sys/sparcv9/doorfs, and if that is not found,
/usr/kernel/sys/sparcv9/doorfs.
The unix kernel, and its dependencies such as genunix, are implicit de‐
pendencies of all other kernel modules, and are not listed as dependen‐
cies by those modules. kldd supplies them implicitly, as needed. If the
-k option is used, kldd uses the kernel specified. Failing that, if the
-P option is used, kldd looks under each specified platform directory
in turn, until a unix kernel is found. If neither -k, nor -P, are spec‐
ified, the path of the kernel from the running system is used.
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 _ Availabilitysystem/linker
SEE ALSO
dump(1), elfdump(1), elfedit(1), ld(1), ldd(1), ldd(1), attributes(7),
modinfo(8)
Oracle Solaris 11.4 Linkers and Libraries Guide
DIAGNOSTICS
kldd prints the record of object path names to stdout. The optional
list of symbol resolution problems is printed to stderr. If file is not
a kernel module or if file cannot be opened for reading, a non-zero
exit status is returned.
NOTES
The following options depend on symbol resolution, and automatically
enable the -r option: -c, -m, -p, -U, -u, and -w.
Ideally, all kernel modules should fully define their dependencies. The
use of the kldd -r option verifies that this is the case. However, in
practice, a kernel module for which the -r option reports missing de‐
pendencies may still be able to load successfully. This can occur if
symbols reported by kldd as unresolved are provided by other kernel
modules that have already been loaded into the system.
The kernel runtime loader, krtld allows required dependency names to
contain the token $CPU. krtld substitutes a string specific to the run‐
ning system for this token. By default, the kldd utility replaces $CPU
with the string generic, which is a valid CPU string on all systems. As
a result, kldd will display the path for the generic module, rather
than the cpu-specific one that may instead be selected by the kernel.
The results are generally equivalent for the purposes of dependency
analysis. The -D option can be used to specify a different translation
for $CPU in cases where the generic version is insufficient.
The kldd command is provided in non-global zones in order to support
the analysis of user built kernel objects. However, note that the di‐
rectories searched for kernel modules and the unix kernel, are not
present in a non-global zone. To use kldd in a non-global zone, it is
necessary to use the -S option to provide a system root directory con‐
taining those files.
The kernel runtime linker, krtld, supports an obsolete, deprecated
mechanism for defining kernel module dependencies in which the kernel
module defined a local string array named _depends_on[] to provide the
dependencies. This mechanism, which is only supported for older kernel
modules not linked with the ld -ztype=kmod option, is not recommended.
However, kldd supports _depends_on[], for older modules only, to allow
for the analysis of existing objects.
EXAMPLES
Example 1 Displaying module dependencies by file path
The following example displays dependencies of the misc/idmap kernel
module, specified by its file path.
$ kldd /kernel/misc/amd64/idmap
sys/doorfs => /kernel/sys/amd64/doorfs
strmod/rpcmod => /kernel/strmod/amd64/rpcmod
misc/tlimod => /kernel/misc/amd64/tlimod
unix (parent) => /platform/i86pc/kernel/amd64/unix
genunix (parent dependency) => /kernel/amd64/genunix
Example 2 Displaying module dependencies by soname
The following example displays dependencies of the misc/idmap kernel
module, specified by its module soname.
$ kldd misc/idmap
sys/doorfs => /kernel/sys/amd64/doorfs
strmod/rpcmod => /kernel/strmod/amd64/rpcmod
misc/tlimod => /kernel/misc/amd64/tlimod
unix (parent) => /platform/i86pc/kernel/amd64/unix
genunix (parent dependency) => /kernel/amd64/genunix
Example 3 Displaying module dependencies by modinfo ID
The following example demonstrates the use of the modinfo utility to
display the dependencies of the misc/sha2 kernel module currently
loaded on the system.
$ modinfo -i misc/sha2
ID LOADADDR SIZE INFO REV NAMEDESC
54 -- be68 -- 1 sha2 (SHA2 Message-Digest Algorithm)
54 -- be68 -- 1 sha2 (SHA2 Kernel SW Provider)
$ kldd `modinfo -i sha2 -o path -p | uniq`
misc/kcf => /kernel/misc/amd64/kcf
unix (parent) => /platform/i86pc/kernel/amd64/unix
genunix (parent dependency) => /kernel/amd64/genunix
Example 4 Viewing search path details
The following example displays dependencies of the misc/idmap kernel
module, showing the search details.
$ kldd -s misc/idmap
search path=/platform/i86pc/kernel:/kernel:/usr/kernel (default)
trying path=/platform/i86pc/kernel/misc/amd64/idmap
trying path=/kernel/misc/amd64/idmap
find module=sys/doorfs; required by /kernel/misc/amd64/idmap
trying path=/platform/i86pc/kernel/sys/amd64/doorfs
trying path=/kernel/sys/amd64/doorfs
sys/doorfs => /kernel/sys/amd64/doorfs
find module=strmod/rpcmod; required by /kernel/misc/amd64/idmap
trying path=/platform/i86pc/kernel/strmod/amd64/rpcmod
trying path=/kernel/strmod/amd64/rpcmod
strmod/rpcmod => /kernel/strmod/amd64/rpcmod
find module=misc/tlimod; required by /kernel/strmod/amd64/rpcmod
trying path=/platform/i86pc/kernel/misc/amd64/tlimod
trying path=/kernel/misc/amd64/tlimod
misc/tlimod => /kernel/misc/amd64/tlimod
find kernel=unix; implicit
trying path=/platform/i86pc/kernel/amd64/unix
unix => /platform/i86pc/kernel/amd64/unix
find module=genunix; required by /platform/i86pc/kernel/amd64/unix
trying path=/platform/i86pc/kernel/amd64/genunix
trying path=/kernel/amd64/genunix
genunix => /kernel/amd64/genunix
Example 5 Exposing module deficiencies
The following example employs a pair of kernel modules, demo/mod_a, and
demo/mod_b, which have not been installed on the running system, and
which are therefore found in a directory named /local/test. The -R op‐
tion is used to allow kldd to locate them. These modules have inten‐
tionally been built with some deficiences in order to demonstrate the
operation of the -p, -r, -U, and -w options.
This output has been formatted for display purposes, and errors not di‐
rectly related to mod_a or mod_b have been omitted.
$ kldd -prUw -R real demo/mod_b
demo/mod_a => /local/test/demo/amd64/mod_a
misc/sha2 => /kernel/misc/amd64/sha2
misc/kcf => /kernel/misc/amd64/kcf
unix (parent) => /platform/i86pc/kernel/amd64/unix
genunix (parent dependency) => /kernel/amd64/genunix
symbol not found: extern_sym (/local/test/demo/amd64/mod_a)
symbol not found: parent_sym (/local/test/demo/amd64/mod_a)
symbol not found: weakref_sym (/local/test/demo/amd64/mod_a)
unreferenced object=/kernel/misc/amd64/sha2;
unused dependency of /local/test/demo/amd64/mod_a
Example 6 Specifying a non-default CPU module
By default, kldd replaces $CPU tokens in dependency names with generic.
The -D option can be used to specify a different version of the cpu
module. This output has been formatted for display purposes.
$ kldd misc/bignum | grep cpu
cpu/$CPU (parent dependency) =>
/platform/sun4v/kernel/cpu/sparcv9/generic
$ kldd -DCPU=SPARC-T5 misc/bignum | grep cpu
cpu/$CPU (parent dependency) =>
/platform/sun4v/kernel/cpu/sparcv9/SPARC-T5
Example 7 Specifying a non-default platform
On an x86 system, analyzing kernel objects found under /platform/i86hvm
requires both the i86pc and i86hvm platforms. The drv/balloon kernel
module is an example of such a case.
$ kldd drv/balloon
drv/balloon: open: No such file or directory
$ kldd -Pi86pc,i86hvm drv/balloon
drv/xpv => /platform/i86hvm/kernel/drv/amd64/xpv
unix (parent) => /platform/i86pc/kernel/amd64/unix
genunix (parent dependency) => /kernel/amd64/genunix
Example 8 Using the system root as a backstop
A common use of kldd is to analyze kernel objects built and delivered
into a local proto directory. Such proto directories may not be com‐
plete system images, and instead rely in objects found in the system
root directory /. The -S option is typically used to point kldd at the
local proto. In order to use the system as a backstop for objects not
present locally, the system root should be included as well. The fol‐
lowing illustrates such use, for a module misc/lproduct, residing in a
proto area /local/lproduct/proto.
$ kldd -S/local/lproduct/proto:/ misc/lproduct
HISTORY
The -S option was extended to accept a path rather than a single system
root, the -P option was added, and support for the deprecated _de‐
pends_on[] mechanism was added, in Oracle Solaris 11.4.64.
The -D option was added in Oracle Solaris 11.4.36.
The kldd command was introduced in the Oracle Solaris 11.4.0 release.
Oracle Solaris 11.4 27 October 2023 kldd(1)