LD.ELF_SO(1) | General Commands Manual | LD.ELF_SO(1) |
ld.elf_so
—
ld.elf_so
is a self-contained, position independent
program image providing run-time support for loading and link-editing shared
objects into a process' address space. It uses information stored in data
structures within the binary (see
elf(5)) and environment variables
to determine which shared objects are needed. These shared objects are loaded
at a convenient virtual address using the
mmap(2) system call. After all
shared objects have been successfully loaded,
ld.elf_so
proceeds to resolve external references from
both the main program and all objects loaded. Once all required references are
resolved control is passed to the program via its entry point.
ld.elf_so
is loaded is also supplied.
DT_NEEDED
entry within the dynamic
section. Each DT_NEEDED
entry refers to a filename
string of the shared object that is to be searched for.
The linker will search for libraries in three lists of paths:
The use of ld.so.conf should be avoided as the setting of a global search path can present a security risk.
DT_RPATH
and DT_RUNPATH
entries in the dynamic section. This is defined at shared object link
time.Dynamic loading via
dlopen(3) uses the
DT_RPATH
and DT_RUNPATH
entries of the main binary, independently of which object the call came
from.
ld.elf_so
will expand the following
variables if present in the paths:
kern.ostype
sysctl(3).kern.osrelease
sysctl(3).hw.machine_arch
sysctl(3).Both ${VARIABLE}
and
$VARIABLE
are recognized.
The filename string can be considered free form, however, it will almost always take the form lib<name>.so.<number>, where name specifies the ‘library’ name and number is conceptually the library's major version number.
This name and another of the form lib<name>.so are normally symbolic links to the real shared object which has a filename of the form lib<name>.so.<major>.<minor>[.<teeny>]. This naming convention allows a versioning scheme similar to a.out(5).
ld.elf_so
will perform all necessary relocations
immediately except for relocations relating to the Procedure Linkage Table
(PLT). The PLT is used as an indirection method for procedure calls to
globally defined functions. It allows, through the use of intermediate code,
the delayed binding of a call to a globally defined function to be performed
at procedure call time. This ‘lazy’ method is the default (see
LD_BIND_NOW).
The DT_INIT
and
DT_FINI
entries in the dynamic section specify the
addresses of the initialization and termination functions, respectively, for
the shared object. ld.elf_so
arranges for each
initialization function to be called before control is passed to the program
and for the termination functions to be called by using
atexit(3).
This mechanism is exploited by the system-supplied constructor initialization and destructor code located in /usr/lib/crtbeginS.o and /usr/lib/crtendS.o. These files are automatically included by cc(1) and c++(1) in the list of object-code files passed to ld(1) when building a shared C or C++ object.
ld.elf_so
.
LD_LIBRARY_PATH
LD_PRELOAD
LD_BIND_NOW
LD_DEBUG
ld.elf_so
was compiled with
debugging support (-DDEBUG).The path expansion variables first appeared in Solaris 10, and in NetBSD 5.0.
LD_LIBRARY_PATH
and
LD_PRELOAD
are not honored when executing in a
set-user-ID or set-group-ID environment. This action is taken to prevent
malicious substitution of shared object dependencies or interposition of
symbols.
April 15, 2019 | NetBSD 9.4 |