As mentioned above, the set of diagnostics may change between the GNU C Library releases. Nevertheless, the following table documents a few common diagnostic items. All numbers are in hexadecimal, with a ‘0x’ prefix.
dl_dst_lib=stringThe $LIB dynamic string token expands to string.
dl_hwcap=integer ¶dl_hwcap2=integerThe HWCAP and HWCAP2 values, as returned for getauxval, and as
used in other places depending on the architecture.
dl_pagesize=integer ¶The system page size is integer bytes.
dl_platform=stringThe $PLATFORM dynamic string token expands to string.
dso.libc=stringThis is the soname of the shared libc object that is part of
the GNU C Library. On most architectures, this is libc.so.6.
env[index]=stringenv_filtered[index]=stringAn environment variable from the process environment. The integer
index is the array index in the environment array. Variables
under env include the variable value after the ‘=’ (assuming
that it was present), variables under env_filtered do not.
path.prefix=stringThis indicates that the GNU C Library was configured using ‘--prefix=string’.
path.sysconfdir=stringThe GNU C Library was configured (perhaps implicitly) with
‘--sysconfdir=string’ (typically /etc).
path.system_dirs[index]=stringThese items list the elements of the built-in array that describes the default library search path. The value string is a directory file name with a trailing ‘/’.
path.rtld=stringThis string indicates the application binary interface (ABI) file name of the run-time dynamic linker.
version.release="stable"version.release="development"The value "stable" indicates that this build of the GNU C Library is
from a release branch. Releases labeled as "development" are
unreleased development versions.
version.version="major.minor" ¶version.version="major.minor.9000"The GNU C Library version. Development releases end in ‘.9000’.
auxv[index].a_type=type ¶auxv[index].a_val=integerauxv[index].a_val_string=stringAn entry in the auxiliary vector (specific to Linux). The values
type (an integer) and integer correspond to the members of
struct auxv. If the value is a string, a_val_string is
used instead of a_val, so that values have consistent types.
The AT_HWCAP and AT_HWCAP2 values in this output do not
reflect adjustment by the GNU C Library.
uname.sysname=stringuname.nodename=stringuname.release=stringuname.version=stringuname.machine=stringuname.domain=stringThese Linux-specific items show the values of struct utsname, as
reported by the uname function. See Platform Type Identification.
aarch64.cpu_features.…These items are specific to the AArch64 architectures. They report data the GNU C Library uses to activate conditionally supported features such as BTI and MTE, and to select alternative function implementations.
aarch64.processor[index].…These are additional items for the AArch64 architecture and are described below.
aarch64.processor[index].requested=kernel-cpuThe kernel is told to run the subsequent probing on the CPU numbered kernel-cpu. The values kernel-cpu and index can be distinct if there are gaps in the process CPU affinity mask. This line is not included if CPU affinity mask information is not available.
aarch64.processor[index].observed=kernel-cpuThis line reports the kernel CPU number kernel-cpu on which the probing code initially ran. If the CPU number cannot be obtained, this line is not printed.
aarch64.processor[index].observed_node=nodeThis reports the observed NUMA node number, as reported by the
getcpu system call. If this information cannot be obtained, this
line is not printed.
aarch64.processor[index].midr_el1=valueThe value of the midr_el1 system register on the processor
index. This line is only printed if the kernel indicates that
this system register is supported.
aarch64.processor[index].dczid_el0=valueThe value of the dczid_el0 system register on the processor
index.
x86.cpu_features.… ¶These items are specific to the i386 and x86-64 architectures. They reflect supported CPU features and information on cache geometry, mostly collected using the CPUID instruction.
x86.processor[index].…These are additional items for the i386 and x86-64 architectures, as
described below. They mostly contain raw data from the CPUID
instruction. The probes are performed for each active CPU for the
ld.so process, and data for different probed CPUs receives a
uniqe index value. Some CPUID data is expected to differ from CPU
core to CPU core. In some cases, CPUs are not correctly initialized and
indicate the presence of different feature sets.
x86.processor[index].requested=kernel-cpuThe kernel is told to run the subsequent probing on the CPU numbered kernel-cpu. The values kernel-cpu and index can be distinct if there are gaps in the process CPU affinity mask. This line is not included if CPU affinity mask information is not available.
x86.processor[index].observed=kernel-cpuThis line reports the kernel CPU number kernel-cpu on which the probing code initially ran. If the CPU number cannot be obtained, this line is not printed.
x86.processor[index].observed_node=nodeThis reports the observed NUMA node number, as reported by the
getcpu system call. If this information cannot be obtained, this
line is not printed.
x86.processor[index].cpuid_leaves=countThis line indicates that count distinct CPUID leaves were
encountered. (This reflects internal ld.so storage space, it
does not directly correspond to CPUID enumeration ranges.)
x86.processor[index].ecx_limit=valueThe CPUID data extraction code uses a brute-force approach to enumerate
subleaves (see the ‘.subleaf_eax’ lines below). The last
%rcx value used in a CPUID query on this probed CPU was
value.
x86.processor[index].cpuid.eax[query_eax].eax=eaxx86.processor[index].cpuid.eax[query_eax].ebx=ebxx86.processor[index].cpuid.eax[query_eax].ecx=ecxx86.processor[index].cpuid.eax[query_eax].edx=edxThese lines report the register contents after executing the CPUID instruction with ‘%rax == query_eax’ and ‘%rcx == 0’ (a leaf). For the first probed CPU (with a zero index), only leaves with non-zero register contents are reported. For subsequent CPUs, only leaves whose register contents differs from the previously probed CPUs (with index one less) are reported.
Basic and extended leaves are reported using the same syntax. This means there is a large jump in query_eax for the first reported extended leaf.
x86.processor[index].cpuid.subleaf_eax[query_eax].ecx[query_ecx].eax=eaxx86.processor[index].cpuid.subleaf_eax[query_eax].ecx[query_ecx].ebx=ebxx86.processor[index].cpuid.subleaf_eax[query_eax].ecx[query_ecx].ecx=ecxx86.processor[index].cpuid.subleaf_eax[query_eax].ecx[query_ecx].edx=edxThis is similar to the leaves above, but for a subleaf. For subleaves, the CPUID instruction is executed with ‘%rax == query_eax’ and ‘%rcx == query_ecx’, so the result depends on both register values. The same rules about filtering zero and identical results apply.
x86.processor[index].cpuid.subleaf_eax[query_eax].ecx[query_ecx].until_ecx=ecx_limitSome CPUID results are the same regardless the query_ecx value.
If this situation is detected, a line with the ‘.until_ecx’
selector ins included, and this indicates that the CPUID register
contents is the same for %rcx values between query_ecx
and ecx_limit (inclusive).
x86.processor[index].cpuid.subleaf_eax[query_eax].ecx[query_ecx].ecx_query_mask=0xffThis line indicates that in an ‘.until_ecx’ range, the CPUID
instruction preserved the lowested 8 bits of the input %rcx in
the output %rcx registers. Otherwise, the subleaves in the range
have identical values. This special treatment is necessary to report
compact range information in case such copying occurs (because the
subleaves would otherwise be all different).
x86.processor[index].xgetbv.ecx[query_ecx]=resultThis line shows the 64-bit result value in the %rdx:%rax
register pair after executing the XGETBV instruction with %rcx
set to query_ecx. Zero values and values matching the previously
probed CPU are omitted. Nothing is printed if the system does not
support the XGETBV instruction.