Dynamic Linker Diagnostics Values (The GNU C Library)

#### 37.1.1.2 Dynamic Linker Diagnostics Values ¶

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=string`

  The `$LIB` dynamic string token expands to string.

`dl_hwcap=integer` ¶
`dl_hwcap2=integer`

  The 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=string`

  The `$PLATFORM` dynamic string token expands to string.

`dso.libc=string`

  This 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]=string`
`env_filtered[index]=string`

  An 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=string`

  This indicates that the GNU C Library was configured using ‘`--prefix=string`’.

`path.sysconfdir=string`

  The GNU C Library was configured (perhaps implicitly) with ‘`--sysconfdir=string`’ (typically `/etc`).

`path.system_dirs[index]=string`

  These 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=string`

  This 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=integer`
`auxv[index].a_val_string=string`

  An 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=string`
`uname.nodename=string`
`uname.release=string`
`uname.version=string`
`uname.machine=string`
`uname.domain=string`

  These 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-cpu`

  The 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-cpu`

  This 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=node`

  This 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=value`

  The 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=value`

  The 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 unique 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-cpu`

  The 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-cpu`

  This 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=node`

  This 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=count`

  This 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=value`

  The 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=eax`
`x86.processor[index].cpuid.eax[query_eax].ebx=ebx`
`x86.processor[index].cpuid.eax[query_eax].ecx=ecx`
`x86.processor[index].cpuid.eax[query_eax].edx=edx`

  These 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=eax`
`x86.processor[index].cpuid.subleaf_eax[query_eax].ecx[query_ecx].ebx=ebx`
`x86.processor[index].cpuid.subleaf_eax[query_eax].ecx[query_ecx].ecx=ecx`
`x86.processor[index].cpuid.subleaf_eax[query_eax].ecx[query_ecx].edx=edx`

  This 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_limit`

  Some 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=0xff`

  This line indicates that in an ‘`.until_ecx`’ range, the CPUID instruction preserved the lowest 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]=result`

  This 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.