Adding upstream version 4.22.0.upstream/4.22.0

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 930 insertions, 0 deletions

diff --git a/upstream/fedora-rawhide/man8/ld.so.8 b/upstream/fedora-rawhide/man8/ld.so.8
new file mode 100644
index 00000000..39ca874f
--- /dev/null
+++ b/upstream/fedora-rawhide/man8/ld.so.8
@@ -0,0 +1,930 @@
+.\" %%%LICENSE_START(PUBLIC_DOMAIN)
+.\" This is in the public domain
+.\" %%%LICENSE_END
+.\" Various parts:
+.\" Copyright (C) 2007-9, 2013, 2016 Michael Kerrisk <mtk.manpages@gmail.com>
+.\"
+.TH ld.so 8 2024-02-12 "Linux man-pages 6.06"
+.SH NAME
+ld.so, ld\-linux.so \- dynamic linker/loader
+.SH SYNOPSIS
+The dynamic linker can be run either indirectly by running some
+dynamically linked program or shared object
+(in which case no command-line options
+to the dynamic linker can be passed and, in the ELF case, the dynamic linker
+which is stored in the
+.B .interp
+section of the program is executed) or directly by running:
+.P
+.I /lib/ld\-linux.so.*
+[OPTIONS] [PROGRAM [ARGUMENTS]]
+.SH DESCRIPTION
+The programs
+.B ld.so
+and
+.B ld\-linux.so*
+find and load the shared objects (shared libraries) needed by a program,
+prepare the program to run, and then run it.
+.P
+Linux binaries require dynamic linking (linking at run time)
+unless the
+.B \-static
+option was given to
+.BR ld (1)
+during compilation.
+.P
+The program
+.B ld.so
+handles a.out binaries, a binary format used long ago.
+The program
+.B ld\-linux.so*
+(\fI/lib/ld\-linux.so.1\fP for libc5, \fI/lib/ld\-linux.so.2\fP for glibc2)
+handles binaries that are in the more modern ELF format.
+Both programs have the same behavior, and use the same
+support files and programs
+.RB ( ldd (1),
+.BR ldconfig (8),
+and
+.IR /etc/ld.so.conf ).
+.P
+When resolving shared object dependencies,
+the dynamic linker first inspects each dependency
+string to see if it contains a slash (this can occur if
+a shared object pathname containing slashes was specified at link time).
+If a slash is found, then the dependency string is interpreted as
+a (relative or absolute) pathname,
+and the shared object is loaded using that pathname.
+.P
+If a shared object dependency does not contain a slash,
+then it is searched for in the following order:
+.IP (1) 5
+Using the directories specified in the
+DT_RPATH dynamic section attribute
+of the binary if present and DT_RUNPATH attribute does not exist.
+Use of DT_RPATH is deprecated.
+.IP (2)
+Using the environment variable
+.BR LD_LIBRARY_PATH ,
+unless the executable is being run in secure-execution mode (see below),
+in which case this variable is ignored.
+.IP (3)
+Using the directories specified in the
+DT_RUNPATH dynamic section attribute
+of the binary if present.
+Such directories are searched only to
+find those objects required by DT_NEEDED (direct dependencies) entries
+and do not apply to those objects' children,
+which must themselves have their own DT_RUNPATH entries.
+This is unlike DT_RPATH, which is applied
+to searches for all children in the dependency tree.
+.IP (4)
+From the cache file
+.IR /etc/ld.so.cache ,
+which contains a compiled list of candidate shared objects previously found
+in the augmented library path.
+If, however, the binary was linked with the
+.B \-z nodefaultlib
+linker option, shared objects in the default paths are skipped.
+Shared objects installed in hardware capability directories (see below)
+are preferred to other shared objects.
+.IP (5)
+In the default path
+.IR /lib ,
+and then
+.IR /usr/lib .
+(On some 64-bit architectures, the default paths for 64-bit shared objects are
+.IR /lib64 ,
+and then
+.IR /usr/lib64 .)
+If the binary was linked with the
+.B \-z nodefaultlib
+linker option, this step is skipped.
+.\"
+.SS Dynamic string tokens
+In several places, the dynamic linker expands dynamic string tokens:
+.IP \[bu] 3
+In the environment variables
+.BR LD_LIBRARY_PATH ,
+.BR LD_PRELOAD ,
+and
+.BR LD_AUDIT ,
+.IP \[bu]
+inside the values of the dynamic section tags
+.BR DT_NEEDED ,
+.BR DT_RPATH ,
+.BR DT_RUNPATH ,
+.BR DT_AUDIT ,
+and
+.B DT_DEPAUDIT
+of ELF binaries,
+.IP \[bu]
+in the arguments to the
+.B ld.so
+command line options
+.BR \-\-audit ,
+.BR \-\-library\-path ,
+and
+.B \-\-preload
+(see below), and
+.IP \[bu]
+in the filename arguments to the
+.BR dlopen (3)
+and
+.BR dlmopen (3)
+functions.
+.P
+The substituted tokens are as follows:
+.TP
+.IR $ORIGIN " (or equivalently " ${ORIGIN} )
+This expands to
+the directory containing the program or shared object.
+Thus, an application located in
+.I somedir/app
+could be compiled with
+.IP
+.in +4n
+.EX
+gcc \-Wl,\-rpath,\[aq]$ORIGIN/../lib\[aq]
+.EE
+.in
+.IP
+so that it finds an associated shared object in
+.I somedir/lib
+no matter where
+.I somedir
+is located in the directory hierarchy.
+This facilitates the creation of "turn-key" applications that
+do not need to be installed into special directories,
+but can instead be unpacked into any directory
+and still find their own shared objects.
+.TP
+.IR $LIB " (or equivalently " ${LIB} )
+This expands to
+.I lib
+or
+.I lib64
+depending on the architecture
+(e.g., on x86-64, it expands to
+.I lib64
+and
+on x86-32, it expands to
+.IR lib ).
+.TP
+.IR $PLATFORM " (or equivalently " ${PLATFORM} )
+This expands to a string corresponding to the processor type
+of the host system (e.g., "x86_64").
+On some architectures, the Linux kernel doesn't provide a platform
+string to the dynamic linker.
+The value of this string is taken from the
+.B AT_PLATFORM
+value in the auxiliary vector (see
+.BR getauxval (3)).
+.\" To get an idea of the places that $PLATFORM would match,
+.\" look at the output of the following:
+.\"
+.\"     mkdir /tmp/d
+.\"     LD_LIBRARY_PATH=/tmp/d strace -e open /bin/date 2>&1 | grep /tmp/d
+.\"
+.\" ld.so lets names be abbreviated, so $O will work for $ORIGIN;
+.\" Don't do this!!
+.P
+Note that the dynamic string tokens have to be quoted properly when
+set from a shell,
+to prevent their expansion as shell or environment variables.
+.SH OPTIONS
+.TP
+.BR \-\-argv0 " \fIstring\fP (since glibc 2.33)"
+Set
+.I argv[0]
+to the value
+.I string
+before running the program.
+.TP
+.BI \-\-audit " list"
+Use objects named in
+.I list
+as auditors.
+The objects in
+.I list
+are delimited by colons.
+.TP
+.BI \-\-glibc-hwcaps-mask " list"
+only search built-in subdirectories if in
+.IR list .
+.TP
+.BI \-\-glibc-hwcaps-prepend " list"
+Search glibc-hwcaps subdirectories in
+.IR list .
+.TP
+.B \-\-inhibit\-cache
+Do not use
+.IR /etc/ld.so.cache .
+.TP
+.BI \-\-library\-path " path"
+Use
+.I path
+instead of
+.B LD_LIBRARY_PATH
+environment variable setting (see below).
+The names
+.IR ORIGIN ,
+.IR LIB ,
+and
+.I PLATFORM
+are interpreted as for the
+.B LD_LIBRARY_PATH
+environment variable.
+.TP
+.BI \-\-inhibit\-rpath " list"
+Ignore RPATH and RUNPATH information in object names in
+.IR list .
+This option is ignored when running in secure-execution mode (see below).
+The objects in
+.I list
+are delimited by colons or spaces.
+.TP
+.B \-\-list
+List all dependencies and how they are resolved.
+.TP
+.BR \-\-list\-diagnostics " (since glibc 2.33)"
+Print system diagnostic information in a machine-readable format,
+such as some internal loader variables,
+the auxiliary vector
+(see
+.BR getauxval (3)),
+and the environment variables.
+On some architectures,
+the command might print additional information
+(like the cpu features used in GNU indirect function selection on x86).
+.BR \-\-list\-tunables " (since glibc 2.33)"
+Print the names and values of all tunables,
+along with the minimum and maximum allowed values.
+.TP
+.BR \-\-preload " \fIlist\fP (since glibc 2.30)"
+Preload the objects specified in
+.IR list .
+The objects in
+.I list
+are delimited by colons or spaces.
+The objects are preloaded as explained in the description of the
+.B LD_PRELOAD
+environment variable below.
+.IP
+By contrast with
+.BR LD_PRELOAD ,
+the
+.B \-\-preload
+option provides a way to perform preloading for a single executable
+without affecting preloading performed in any child process that executes
+a new program.
+.TP
+.B \-\-verify
+Verify that program is dynamically linked and this dynamic linker can handle
+it.
+.SH ENVIRONMENT
+Various environment variables influence the operation of the dynamic linker.
+.\"
+.SS Secure-execution mode
+For security reasons,
+if the dynamic linker determines that a binary should be
+run in secure-execution mode,
+the effects of some environment variables are voided or modified,
+and furthermore those environment variables are stripped from the environment,
+so that the program does not even see the definitions.
+Some of these environment variables affect the operation of
+the dynamic linker itself, and are described below.
+Other environment variables treated in this way include:
+.BR GCONV_PATH ,
+.BR GETCONF_DIR ,
+.BR HOSTALIASES ,
+.BR LOCALDOMAIN ,
+.BR LD_AUDIT ,
+.BR LD_DEBUG ,
+.BR LD_DEBUG_OUTPUT ,
+.BR LD_DYNAMIC_WEAK ,
+.BR LD_HWCAP_MASK ,
+.BR LD_LIBRARY_PATH ,
+.BR LD_ORIGIN_PATH ,
+.BR LD_PRELOAD ,
+.BR LD_PROFILE ,
+.BR LD_SHOW_AUXV ,
+.BR LOCALDOMAIN ,
+.BR LOCPATH ,
+.BR MALLOC_TRACE ,
+.BR NIS_PATH ,
+.BR NLSPATH ,
+.BR RESOLV_HOST_CONF ,
+.BR RES_OPTIONS ,
+.BR TMPDIR ,
+and
+.BR TZDIR .
+.P
+A binary is executed in secure-execution mode if the
+.B AT_SECURE
+entry in the auxiliary vector (see
+.BR getauxval (3))
+has a nonzero value.
+This entry may have a nonzero value for various reasons, including:
+.IP \[bu] 3
+The process's real and effective user IDs differ,
+or the real and effective group IDs differ.
+This typically occurs as a result of executing
+a set-user-ID or set-group-ID program.
+.IP \[bu]
+A process with a non-root user ID executed a binary that
+conferred capabilities to the process.
+.IP \[bu]
+A nonzero value may have been set by a Linux Security Module.
+.\"
+.SS Environment variables
+Among the more important environment variables are the following:
+.TP
+.BR LD_ASSUME_KERNEL " (from glibc 2.2.3 to glibc 2.36)"
+Each shared object can inform the dynamic linker of the minimum kernel ABI
+version that it requires.
+(This requirement is encoded in an ELF note section that is viewable via
+.I readelf\~\-n
+as a section labeled
+.BR NT_GNU_ABI_TAG .)
+At run time,
+the dynamic linker determines the ABI version of the running kernel and
+will reject loading shared objects that specify minimum ABI versions
+that exceed that ABI version.
+.IP
+.B LD_ASSUME_KERNEL
+can be used to
+cause the dynamic linker to assume that it is running on a system with
+a different kernel ABI version.
+For example, the following command line causes the
+dynamic linker to assume it is running on Linux 2.2.5 when loading
+the shared objects required by
+.IR myprog :
+.IP
+.in +4n
+.EX
+$ \fBLD_ASSUME_KERNEL=2.2.5 ./myprog\fP
+.EE
+.in
+.IP
+On systems that provide multiple versions of a shared object
+(in different directories in the search path) that have
+different minimum kernel ABI version requirements,
+.B LD_ASSUME_KERNEL
+can be used to select the version of the object that is used
+(dependent on the directory search order).
+.IP
+Historically, the most common use of the
+.B LD_ASSUME_KERNEL
+feature was to manually select the older
+LinuxThreads POSIX threads implementation on systems that provided both
+LinuxThreads and NPTL
+(which latter was typically the default on such systems);
+see
+.BR pthreads (7).
+.TP
+.BR LD_BIND_NOW " (since glibc 2.1.1)"
+If set to a nonempty string,
+causes the dynamic linker to resolve all symbols
+at program startup instead of deferring function call resolution to the point
+when they are first referenced.
+This is useful when using a debugger.
+.TP
+.B LD_LIBRARY_PATH
+A list of directories in which to search for
+ELF libraries at execution time.
+The items in the list are separated by either colons or semicolons,
+and there is no support for escaping either separator.
+A zero-length directory name indicates the current working directory.
+.IP
+This variable is ignored in secure-execution mode.
+.IP
+Within the pathnames specified in
+.BR LD_LIBRARY_PATH ,
+the dynamic linker expands the tokens
+.IR $ORIGIN ,
+.IR $LIB ,
+and
+.I $PLATFORM
+(or the versions using curly braces around the names)
+as described above in
+.IR "Dynamic string tokens" .
+Thus, for example,
+the following would cause a library to be searched for in either the
+.I lib
+or
+.I lib64
+subdirectory below the directory containing the program to be executed:
+.IP
+.in +4n
+.EX
+$ \fBLD_LIBRARY_PATH=\[aq]$ORIGIN/$LIB\[aq] prog\fP
+.EE
+.in
+.IP
+(Note the use of single quotes, which prevent expansion of
+.I $ORIGIN
+and
+.I $LIB
+as shell variables!)
+.TP
+.B LD_PRELOAD
+A list of additional, user-specified, ELF shared
+objects to be loaded before all others.
+This feature can be used to selectively override functions
+in other shared objects.
+.IP
+The items of the list can be separated by spaces or colons,
+and there is no support for escaping either separator.
+The objects are searched for using the rules given under DESCRIPTION.
+Objects are searched for and added to the link map in the left-to-right
+order specified in the list.
+.IP
+In secure-execution mode,
+preload pathnames containing slashes are ignored.
+Furthermore, shared objects are preloaded only
+from the standard search directories and only
+if they have set-user-ID mode bit enabled (which is not typical).
+.IP
+Within the names specified in the
+.B LD_PRELOAD
+list, the dynamic linker understands the tokens
+.IR $ORIGIN ,
+.IR $LIB ,
+and
+.I $PLATFORM
+(or the versions using curly braces around the names)
+as described above in
+.IR "Dynamic string tokens" .
+(See also the discussion of quoting under the description of
+.BR LD_LIBRARY_PATH .)
+.\" Tested with the following:
+.\"
+.\"	LD_PRELOAD='$LIB/libmod.so' LD_LIBRARY_PATH=. ./prog
+.\"
+.\" which will preload the libmod.so in 'lib' or 'lib64', using it
+.\" in preference to the version in '.'.
+.IP
+There are various methods of specifying libraries to be preloaded,
+and these are handled in the following order:
+.RS
+.IP (1) 5
+The
+.B LD_PRELOAD
+environment variable.
+.IP (2)
+The
+.B \-\-preload
+command-line option when invoking the dynamic linker directly.
+.IP (3)
+The
+.I /etc/ld.so.preload
+file (described below).
+.RE
+.TP
+.B LD_TRACE_LOADED_OBJECTS
+If set (to any value), causes the program to list its dynamic
+dependencies, as if run by
+.BR ldd (1),
+instead of running normally.
+.P
+Then there are lots of more or less obscure variables,
+many obsolete or only for internal use.
+.TP
+.BR LD_AUDIT " (since glibc 2.4)"
+A list of user-specified, ELF shared objects
+to be loaded before all others in a separate linker namespace
+(i.e., one that does not intrude upon the normal symbol bindings that
+would occur in the process)
+These objects can be used to audit the operation of the dynamic linker.
+The items in the list are colon-separated,
+and there is no support for escaping the separator.
+.IP
+.B LD_AUDIT
+is ignored in secure-execution mode.
+.IP
+The dynamic linker will notify the audit
+shared objects at so-called auditing checkpoints\[em]for example,
+loading a new shared object, resolving a symbol,
+or calling a symbol from another shared object\[em]by
+calling an appropriate function within the audit shared object.
+For details, see
+.BR rtld\-audit (7).
+The auditing interface is largely compatible with that provided on Solaris,
+as described in its
+.IR "Linker and Libraries Guide" ,
+in the chapter
+.IR "Runtime Linker Auditing Interface" .
+.IP
+Within the names specified in the
+.B LD_AUDIT
+list, the dynamic linker understands the tokens
+.IR $ORIGIN ,
+.IR $LIB ,
+and
+.I $PLATFORM
+(or the versions using curly braces around the names)
+as described above in
+.IR "Dynamic string tokens" .
+(See also the discussion of quoting under the description of
+.BR LD_LIBRARY_PATH .)
+.IP
+Since glibc 2.13,
+.\" commit 8e9f92e9d5d7737afdacf79b76d98c4c42980508
+in secure-execution mode,
+names in the audit list that contain slashes are ignored,
+and only shared objects in the standard search directories that
+have the set-user-ID mode bit enabled are loaded.
+.TP
+.BR LD_BIND_NOT " (since glibc 2.1.95)"
+If this environment variable is set to a nonempty string,
+do not update the GOT (global offset table) and PLT (procedure linkage table)
+after resolving a function symbol.
+By combining the use of this variable with
+.B LD_DEBUG
+(with the categories
+.I bindings
+and
+.IR symbols ),
+one can observe all run-time function bindings.
+.TP
+.BR LD_DEBUG " (since glibc 2.1)"
+Output verbose debugging information about operation of the dynamic linker.
+The content of this variable is one of more of the following categories,
+separated by colons, commas, or (if the value is quoted) spaces:
+.RS
+.TP 12
+.I help
+Specifying
+.I help
+in the value of this variable does not run the specified program,
+and displays a help message about which categories can be specified in this
+environment variable.
+.TP
+.I all
+Print all debugging information (except
+.I statistics
+and
+.IR unused ;
+see below).
+.TP
+.I bindings
+Display information about which definition each symbol is bound to.
+.TP
+.I files
+Display progress for input file.
+.TP
+.I libs
+Display library search paths.
+.TP
+.I reloc
+Display relocation processing.
+.TP
+.I scopes
+Display scope information.
+.TP
+.I statistics
+Display relocation statistics.
+.TP
+.I symbols
+Display search paths for each symbol look-up.
+.TP
+.I unused
+Determine unused DSOs.
+.TP
+.I versions
+Display version dependencies.
+.RE
+.IP
+Since glibc 2.3.4,
+.B LD_DEBUG
+is ignored in secure-execution mode, unless the file
+.I /etc/suid\-debug
+exists (the content of the file is irrelevant).
+.TP
+.BR LD_DEBUG_OUTPUT " (since glibc 2.1)"
+By default,
+.B LD_DEBUG
+output is written to standard error.
+If
+.B LD_DEBUG_OUTPUT
+is defined, then output is written to the pathname specified by its value,
+with the suffix "." (dot) followed by the process ID appended to the pathname.
+.IP
+.B LD_DEBUG_OUTPUT
+is ignored in secure-execution mode.
+.TP
+.BR LD_DYNAMIC_WEAK " (since glibc 2.1.91)"
+By default, when searching shared libraries to resolve a symbol reference,
+the dynamic linker will resolve to the first definition it finds.
+.IP
+Old glibc versions (before glibc 2.2), provided a different behavior:
+if the linker found a symbol that was weak,
+it would remember that symbol and
+keep searching in the remaining shared libraries.
+If it subsequently found a strong definition of the same symbol,
+then it would instead use that definition.
+(If no further symbol was found,
+then the dynamic linker would use the weak symbol that it initially found.)
+.IP
+The old glibc behavior was nonstandard.
+(Standard practice is that the distinction between
+weak and strong symbols should have effect only at static link time.)
+In glibc 2.2,
+.\" More precisely 2.1.92
+.\" See weak handling
+.\"     https://www.sourceware.org/ml/libc-hacker/2000-06/msg00029.html
+.\"     To: GNU libc hacker <libc-hacker at sourceware dot cygnus dot com>
+.\"     Subject: weak handling
+.\"     From: Ulrich Drepper <drepper at redhat dot com>
+.\"     Date: 07 Jun 2000 20:08:12 -0700
+.\"     Reply-To: drepper at cygnus dot com (Ulrich Drepper)
+the dynamic linker was modified to provide the current behavior
+(which was the behavior that was provided by most other implementations
+at that time).
+.IP
+Defining the
+.B LD_DYNAMIC_WEAK
+environment variable (with any value) provides
+the old (nonstandard) glibc behavior,
+whereby a weak symbol in one shared library may be overridden by
+a strong symbol subsequently discovered in another shared library.
+(Note that even when this variable is set,
+a strong symbol in a shared library will not override
+a weak definition of the same symbol in the main program.)
+.IP
+Since glibc 2.3.4,
+.B LD_DYNAMIC_WEAK
+is ignored in secure-execution mode.
+.TP
+.BR LD_HWCAP_MASK " (from glibc 2.1 to glibc 2.38)"
+Mask for hardware capabilities.
+Since glibc 2.26,
+the option might be ignored
+if glibc does not support tunables.
+.TP
+.BR LD_ORIGIN_PATH " (since glibc 2.1)"
+Path where the binary is found.
+.\" Used only if $ORIGIN can't be determined by normal means
+.\" (from the origin path saved at load time, or from /proc/self/exe)?
+.IP
+Since glibc 2.4,
+.B LD_ORIGIN_PATH
+is ignored in secure-execution mode.
+.TP
+.BR LD_POINTER_GUARD " (from glibc 2.4 to glibc 2.22)"
+Set to 0 to disable pointer guarding.
+Any other value enables pointer guarding, which is also the default.
+Pointer guarding is a security mechanism whereby some pointers to code
+stored in writable program memory (return addresses saved by
+.BR setjmp (3)
+or function pointers used by various glibc internals) are mangled
+semi-randomly to make it more difficult for an attacker to hijack
+the pointers for use in the event of a buffer overrun or
+stack-smashing attack.
+Since glibc 2.23,
+.\" commit a014cecd82b71b70a6a843e250e06b541ad524f7
+.B LD_POINTER_GUARD
+can no longer be used to disable pointer guarding,
+which is now always enabled.
+.TP
+.BR LD_PROFILE " (since glibc 2.1)"
+The name of a (single) shared object to be profiled,
+specified either as a pathname or a soname.
+Profiling output is appended to the file whose name is:
+.RI \%$LD_PROFILE_OUTPUT /\: $LD_PROFILE .profile .
+.IP
+Since glibc 2.2.5,
+.B LD_PROFILE
+uses a different default path in secure-execution mode.
+.TP
+.BR LD_PROFILE_OUTPUT " (since glibc 2.1)"
+Directory where
+.B LD_PROFILE
+output should be written.
+If this variable is not defined, or is defined as an empty string,
+then the default is
+.IR /var/tmp .
+.IP
+.B LD_PROFILE_OUTPUT
+is ignored in secure-execution mode; instead
+.I /var/profile
+is always used.
+.TP
+.BR LD_SHOW_AUXV " (since glibc 2.1)"
+If this environment variable is defined (with any value),
+show the auxiliary array passed up from the kernel (see also
+.BR getauxval (3)).
+.IP
+Since glibc 2.3.4,
+.B LD_SHOW_AUXV
+is ignored in secure-execution mode.
+.TP
+.BR LD_TRACE_PRELINKING " (from glibc 2.4 to glibc 2.35)"
+If this environment variable is defined,
+trace prelinking of the object whose name is assigned to
+this environment variable.
+(Use
+.BR ldd (1)
+to get a list of the objects that might be traced.)
+If the object name is not recognized,
+.\" (This is what seems to happen, from experimenting)
+then all prelinking activity is traced.
+.TP
+.BR LD_USE_LOAD_BIAS " (from glibc 2.3.3 to glibc 2.35)"
+.\" http://sources.redhat.com/ml/libc-hacker/2003-11/msg00127.html
+.\" Subject: [PATCH] Support LD_USE_LOAD_BIAS
+.\" Jakub Jelinek
+By default (i.e., if this variable is not defined),
+executables and prelinked
+shared objects will honor base addresses of their dependent shared objects
+and (nonprelinked) position-independent executables (PIEs)
+and other shared objects will not honor them.
+If
+.B LD_USE_LOAD_BIAS
+is defined with the value 1, both executables and PIEs
+will honor the base addresses.
+If
+.B LD_USE_LOAD_BIAS
+is defined with the value 0,
+neither executables nor PIEs will honor the base addresses.
+.IP
+Since glibc 2.3.3, this variable is ignored in secure-execution mode.
+.TP
+.BR LD_VERBOSE " (since glibc 2.1)"
+If set to a nonempty string,
+output symbol versioning information about the
+program if the
+.B LD_TRACE_LOADED_OBJECTS
+environment variable has been set.
+.TP
+.BR LD_WARN " (since glibc 2.1.3)"
+If set to a nonempty string, warn about unresolved symbols.
+.TP
+.BR LD_PREFER_MAP_32BIT_EXEC " (x86-64 only; since glibc 2.23)"
+According to the Intel Silvermont software optimization guide, for 64-bit
+applications, branch prediction performance can be negatively impacted
+when the target of a branch is more than 4\ GB away from the branch.
+If this environment variable is set (to any value),
+the dynamic linker
+will first try to map executable pages using the
+.BR mmap (2)
+.B MAP_32BIT
+flag, and fall back to mapping without that flag if that attempt fails.
+NB: MAP_32BIT will map to the low 2\ GB (not 4\ GB) of the address space.
+.IP
+Because
+.B MAP_32BIT
+reduces the address range available for address space layout
+randomization (ASLR),
+.B LD_PREFER_MAP_32BIT_EXEC
+is always disabled in secure-execution mode.
+.SH FILES
+.TP
+.I /lib/ld.so
+a.out dynamic linker/loader
+.TP
+.IR /lib/ld\-linux.so. { 1 , 2 }
+ELF dynamic linker/loader
+.TP
+.I /etc/ld.so.cache
+File containing a compiled list of directories in which to search for
+shared objects and an ordered list of candidate shared objects.
+See
+.BR ldconfig (8).
+.TP
+.I /etc/ld.so.preload
+File containing a whitespace-separated list of ELF shared objects to
+be loaded before the program.
+See the discussion of
+.B LD_PRELOAD
+above.
+If both
+.B LD_PRELOAD
+and
+.I /etc/ld.so.preload
+are employed, the libraries specified by
+.B LD_PRELOAD
+are preloaded first.
+.I /etc/ld.so.preload
+has a system-wide effect,
+causing the specified libraries to be preloaded for
+all programs that are executed on the system.
+(This is usually undesirable,
+and is typically employed only as an emergency remedy, for example,
+as a temporary workaround to a library misconfiguration issue.)
+.TP
+.I lib*.so*
+shared objects
+.SH NOTES
+.SS Legacy Hardware capabilities (from glibc 2.5 to glibc 2.37)
+Some shared objects are compiled using hardware-specific instructions which do
+not exist on every CPU.
+Such objects should be installed in directories whose names define the
+required hardware capabilities, such as
+.IR /usr/lib/sse2/ .
+The dynamic linker checks these directories against the hardware of the
+machine and selects the most suitable version of a given shared object.
+Hardware capability directories can be cascaded to combine CPU features.
+The list of supported hardware capability names depends on the CPU.
+The following names are currently recognized:
+.\" Presumably, this info comes from sysdeps/i386/dl-procinfo.c and
+.\" similar files
+.TP
+.B Alpha
+ev4, ev5, ev56, ev6, ev67
+.TP
+.B MIPS
+loongson2e, loongson2f, octeon, octeon2
+.TP
+.B PowerPC
+4xxmac, altivec, arch_2_05, arch_2_06, booke, cellbe, dfp, efpdouble, efpsingle,
+fpu, ic_snoop, mmu, notb, pa6t, power4, power5, power5+, power6x, ppc32, ppc601,
+ppc64, smt, spe, ucache, vsx
+.TP
+.B SPARC
+flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2
+.TP
+.B s390
+dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle,
+z900, z990, z9-109, z10, zarch
+.TP
+.B x86 (32-bit only)
+acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586, i686, mca, mmx,
+mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm
+.P
+The legacy hardware capabilities support has the drawback that
+each new feature added grows the search path exponentially,
+because it has to be added to
+every combination of the other existing features.
+.P
+For instance, on x86 32-bit,
+if the hardware supports
+.B i686
+and
+.BR sse2 ,
+the resulting search path will be
+.BR i686/sse2:i686:sse2:. .
+A new capability
+.B newcap
+will set the search path to
+.BR newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2: .
+.\"
+.SS glibc Hardware capabilities (from glibc 2.33)
+.TP
+.\" The initial discussion on various pitfalls of the old scheme is
+.\" <https://sourceware.org/pipermail/libc-alpha/2020-May/113757.html>
+.\" and the patchset that proposes the glibc-hwcap support is
+.\" <https://sourceware.org/pipermail/libc-alpha/2020-June/115250.html>
+glibc 2.33 added a new hardware capability scheme,
+where under each CPU architecture,
+certain levels can be defined,
+grouping support for certain features or special instructions.
+Each architecture level has
+a fixed set of paths that it adds to the dynamic linker search list,
+depending on the hardware of the machine.
+Since each new architecture level is
+not combined with previously existing ones,
+the new scheme does not have the drawback of
+growing the dynamic linker search list uncontrollably.
+.P
+For instance, on x86 64-bit,
+if the hardware supports
+.B x86_64-v3
+(for instance Intel Haswell or AMD Excavator),
+the resulting search path will be
+.B glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:.
+.\" The x86_64 architectures levels are defined the official ABI:
+.\" <https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex>
+.\" The PowerPC and s390x are glibc defined ones based on chip
+.\" support (which maps to ISA levels).
+The following paths are currently supported, in priority order.
+.TP
+.B PowerPC (64-bit little-endian only)
+power10, power9
+.TP
+.B s390 (64-bit only)
+z16, z15, z14, z13
+.TP
+.B x86 (64-bit only)
+x86-64-v4, x86-64-v3, x86-64-v2
+.P
+glibc 2.37 removed support for the legacy hardware capabilities.
+.\"
+.SH SEE ALSO
+.BR ld (1),
+.BR ldd (1),
+.BR pldd (1),
+.BR sprof (1),
+.BR dlopen (3),
+.BR getauxval (3),
+.BR elf (5),
+.BR capabilities (7),
+.BR rtld\-audit (7),
+.BR ldconfig (8),
+.BR sln (8)
+.\" .SH AUTHORS
+.\" ld.so: David Engel, Eric Youngdale, Peter MacDonald, Hongjiu Lu, Linus
+.\"  Torvalds, Lars Wirzenius and Mitch D'Souza
+.\" ld\-linux.so: Roland McGrath, Ulrich Drepper and others.
+.\"
+.\" In the above, (libc5) stands for David Engel's ld.so/ld\-linux.so.