qiurui
/
glibc
mirror of git://sourceware.org/git/glibc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
glibc/sysdeps/s390/cpu-features.c

231 lines
7.9 KiB
C
Raw Normal View History

S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
/* Initialize cpu feature data. s390x version.
Update copyright dates with scripts/update-copyrights
2025-01-01 18:14:45 +00:00
Copyright (C) 2023-2025 Free Software Foundation, Inc.
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<https://www.gnu.org/licenses/>. */
#include <cpu-features.h>
Remove unused dl-procinfo.h Remove unused _dl_hwcap_string defines. As a result many dl-procinfo.h headers can be removed. This also removes target specific _dl_procinfo implementations which only printed HWCAP strings using dl_hwcap_string. Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2025-02-28 16:52:25 +00:00
#include <ldsodefs.h>
#include <sys/auxv.h>
Remove --enable-tunables configure option And make always supported. The configure option was added on glibc 2.25 and some features require it (such as hwcap mask, huge pages support, and lock elisition tuning). It also simplifies the build permutations. Changes from v1: * Remove glibc.rtld.dynamic_sort changes, it is orthogonal and needs more discussion. * Cleanup more code. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-03-23 13:13:51 +00:00
#include <elf/dl-tunables.h>
#include <ifunc-memcmp.h>
#include <string.h>
s390: Use dl-symbol-redir-ifunc.h on cpu-tunables Using the memcmp symbol directly allows the compile to inline the memcmp calls (especially because _dl_tunable_set_hwcaps uses constants values), generating better code. Checked with tst-tunables on s390x-linux-gnu (qemu system). Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-11-06 20:25:43 +00:00
#include <dl-symbol-redir-ifunc.h>
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
#include <dl-tunables-parse.h>
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
Remove --enable-tunables configure option And make always supported. The configure option was added on glibc 2.25 and some features require it (such as hwcap mask, huge pages support, and lock elisition tuning). It also simplifies the build permutations. Changes from v1: * Remove glibc.rtld.dynamic_sort changes, it is orthogonal and needs more discussion. * Cleanup more code. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-03-23 13:13:51 +00:00
#define S390_COPY_CPU_FEATURES(SRC_PTR, DEST_PTR) \
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
(DEST_PTR)->hwcap = (SRC_PTR)->hwcap; \
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
(DEST_PTR)->stfle_filtered = (SRC_PTR)->stfle_filtered;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
static void
TUNABLE_CALLBACK (set_hwcaps) (tunable_val_t *valp)
{
/* The current IFUNC selection is always using the most recent
features which are available via AT_HWCAP or STFLE-bits. But in
some scenarios it is useful to adjust this selection.
The environment variable:
GLIBC_TUNABLES=glibc.cpu.hwcaps=-xxx,yyy,zzz,....
can be used to enable HWCAP/STFLE feature yyy, disable HWCAP/STFLE feature
xxx, where the feature name is case-sensitive and has to match the ones
used below. Furthermore, the ARCH-level zzz can be used to set various
HWCAP/STFLE features at once. */
/* Copy the features from dl_s390_cpu_features, which contains the features
provided by AT_HWCAP and stfle-instruction. */
struct cpu_features *cpu_features = &GLRO(dl_s390_cpu_features);
struct cpu_features cpu_features_orig;
S390_COPY_CPU_FEATURES (cpu_features, &cpu_features_orig);
struct cpu_features cpu_features_curr;
S390_COPY_CPU_FEATURES (cpu_features, &cpu_features_curr);
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
struct tunable_str_comma_state_t ts;
tunable_str_comma_init (&ts, valp);
struct tunable_str_comma_t t;
while (tunable_str_comma_next (&ts, &t))
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
{
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
if (t.len == 0)
continue;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
/* Handle only the features here which are really used in the
IFUNC-resolvers. All others are ignored as the values are only used
inside glibc. */
bool reset_features = false;
unsigned long int hwcap_mask = 0UL;
unsigned long long stfle_bits0_mask = 0ULL;
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
bool disable = t.disable;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
if (tunable_str_comma_strcmp_cte (&t, "zEC12")
|| tunable_str_comma_strcmp_cte (&t, "arch10"))
{
reset_features = true;
disable = true;
hwcap_mask = HWCAP_S390_VXRS | HWCAP_S390_VXRS_EXT
| HWCAP_S390_VXRS_EXT2;
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
stfle_bits0_mask = S390_STFLE_BIT61_ARCH13_MIE3;
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
}
else if (tunable_str_comma_strcmp_cte (&t, "z13")
|| tunable_str_comma_strcmp_cte (&t, "arch11"))
{
reset_features = true;
disable = true;
hwcap_mask = HWCAP_S390_VXRS_EXT | HWCAP_S390_VXRS_EXT2;
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
stfle_bits0_mask = S390_STFLE_BIT61_ARCH13_MIE3;
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
}
else if (tunable_str_comma_strcmp_cte (&t, "z14")
|| tunable_str_comma_strcmp_cte (&t, "arch12"))
{
reset_features = true;
disable = true;
hwcap_mask = HWCAP_S390_VXRS_EXT2;
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
stfle_bits0_mask = S390_STFLE_BIT61_ARCH13_MIE3;
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
}
else if (tunable_str_comma_strcmp_cte (&t, "z15")
|| tunable_str_comma_strcmp_cte (&t, "z16")
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
|| tunable_str_comma_strcmp_cte (&t, "z17")
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
|| tunable_str_comma_strcmp_cte (&t, "arch13")
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
|| tunable_str_comma_strcmp_cte (&t, "arch14")
|| tunable_str_comma_strcmp_cte (&t, "arch15"))
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
{
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
/* For z15 or newer we don't have to disable something, but we have
to reset to the original values. */
reset_features = true;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
}
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
else if (tunable_str_comma_strcmp_cte (&t, "HWCAP_S390_VXRS"))
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
{
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
hwcap_mask = HWCAP_S390_VXRS;
if (t.disable)
hwcap_mask |= HWCAP_S390_VXRS_EXT | HWCAP_S390_VXRS_EXT2;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
}
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
else if (tunable_str_comma_strcmp_cte (&t, "HWCAP_S390_VXRS_EXT"))
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
{
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
hwcap_mask = HWCAP_S390_VXRS_EXT;
if (t.disable)
hwcap_mask |= HWCAP_S390_VXRS_EXT2;
else
hwcap_mask |= HWCAP_S390_VXRS;
}
else if (tunable_str_comma_strcmp_cte (&t, "HWCAP_S390_VXRS_EXT2"))
{
hwcap_mask = HWCAP_S390_VXRS_EXT2;
if (!t.disable)
hwcap_mask |= HWCAP_S390_VXRS | HWCAP_S390_VXRS_EXT;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
}
elf: Do not duplicate the GLIBC_TUNABLES string The tunable parsing duplicates the tunable environment variable so it null-terminates each one since it simplifies the later parsing. It has the drawback of adding another point of failure (__minimal_malloc failing), and the memory copy requires tuning the compiler to avoid mem operations calls. The parsing now tracks the tunable start and its size. The dl-tunable-parse.h adds helper functions to help parsing, like a strcmp that also checks for size and an iterator for suboptions that are comma-separated (used on hwcap parsing by x86, powerpc, and s390x). Since the environment variable is allocated on the stack by the kernel, it is safe to keep the references to the suboptions for later parsing of string tunables (as done by set_hwcaps by multiple architectures). Checked on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-06 13:24:01 +00:00
else if (tunable_str_comma_strcmp_cte (&t, "STFLE_MIE3"))
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
stfle_bits0_mask = S390_STFLE_BIT61_ARCH13_MIE3;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
/* Perform the actions determined above. */
if (reset_features)
{
S390_COPY_CPU_FEATURES (&cpu_features_orig, &cpu_features_curr);
}
if (hwcap_mask != 0UL)
{
if (disable)
cpu_features_curr.hwcap &= ~hwcap_mask;
else
cpu_features_curr.hwcap |= hwcap_mask;
}
if (stfle_bits0_mask != 0ULL)
{
if (disable)
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
cpu_features_curr.stfle_filtered &= ~stfle_bits0_mask;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
else
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
cpu_features_curr.stfle_filtered |= stfle_bits0_mask;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
}
}
/* Copy back the features after checking that no unsupported features were
enabled by user. */
cpu_features->hwcap = cpu_features_curr.hwcap & cpu_features_orig.hwcap;
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
cpu_features->stfle_filtered = cpu_features_curr.stfle_filtered
& cpu_features_orig.stfle_filtered;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
}
static inline void
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
init_cpu_features_no_tunables (struct cpu_features *cpu_features)
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
{
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
/* Only initialize once. */
if (cpu_features->hwcap != 0)
return;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
/* Fill cpu_features as passed by kernel and machine. */
cpu_features->hwcap = GLRO(dl_hwcap);
/* We want just 1 double word to be returned. */
if (__glibc_likely ((cpu_features->hwcap & HWCAP_S390_STFLE)
&& (cpu_features->hwcap & HWCAP_S390_ZARCH)
&& (cpu_features->hwcap & HWCAP_S390_HIGH_GPRS)))
{
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
unsigned long long stfle_bits[4] = { 0 };
register unsigned long reg0 __asm__("0") = 3;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
__asm__ __volatile__(".machine push" "\n\t"
".machine \"z9-109\"" "\n\t"
".machinemode \"zarch_nohighgprs\"\n\t"
"stfle %0" "\n\t"
".machine pop" "\n"
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
: "=QS" (stfle_bits[0]),
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
"+d" (reg0)
: : "cc");
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
unsigned long long internal_stfle_bits = 0;
/* Facility bit 34: z10: General instructions extension. */
if ((stfle_bits[0] & (1ULL << (63 - 34))) != 0)
internal_stfle_bits |= S390_STFLE_BIT34_Z10;
/* Facility bit 45: z196: Distinct operands, popcount, ... */
if ((stfle_bits[0] & (1ULL << (63 - 45))) != 0)
internal_stfle_bits |= S390_STFLE_BIT45_Z196;
/* Facility bit 61: arch13/z15: Miscellaneous-Instruction-Extensions
Facility 3, e.g. mvcrl. */
if ((stfle_bits[0] & (1ULL << (63 - 61))) != 0)
internal_stfle_bits |= S390_STFLE_BIT61_ARCH13_MIE3;
/* Facility bit 84: arch15/z17: Miscellaneous-instruction-extensions 4 */
if ((stfle_bits[1] & (1ULL << (127 - 84))) != 0)
internal_stfle_bits |= S390_STFLE_BIT84_ARCH15_MIE4;
/* Facility bit 198: arch15/z17: Vector-enhancements-facility 3 */
if ((stfle_bits[3] & (1ULL << (255 - 198))) != 0)
internal_stfle_bits |= S390_STFLE_BIT198_ARCH15_VXRS_EXT3;
/* Facility bit 199: arch15/z17: Vector-Packed-Decimal-Enhancement 3 */
if ((stfle_bits[3] & (1ULL << (255 - 199))) != 0)
internal_stfle_bits |= S390_STFLE_BIT199_ARCH15_VXRS_PDE3;
/* Facility bit 201: arch15/z17: CPU: Concurrent-Functions Facility */
if ((stfle_bits[3] & (1ULL << (255 - 201))) != 0)
internal_stfle_bits |= S390_STFLE_BIT201_ARCH15_CON;
cpu_features->stfle_orig = internal_stfle_bits;
cpu_features->stfle_filtered = internal_stfle_bits;
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
}
S390: Add new s390 platform z17. The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if the z17 facility bits are active: - Miscellaneous-instruction-extensions facility 4 - Vector-enhancements-facility 3 - Vector-Packed-Decimal-Enhancement Facility 3 - CPU: Concurrent-Functions Facility tst-glibc-hwcaps.c is extended in order to test z17 via new marker6. In case of running on a z17 with a kernel not recognizing z17 yet, AT_PLATFORM will be z900 but vector-bit in AT_HWCAP is set. This situation is now recognized and this testcase does not fail. A fatal glibc error is dumped if glibc was build with architecture level set for z17, but run on an older machine (See dl-hwcap-check.h). Note, you might get an SIGILL before this check if you don't use: configure --with-rtld-early-cflags=-march=<older-machine> ld.so --list-diagnostics now also dumps information about s390.cpu_features. Independent from z17, the s390x kernel won't introduce new HWCAP-Bits if there is no special handling needed in kernel itself. For z17, we don't have new HWCAP flags, but have to check the facility bits retrieved by stfle-instruction. Instead of storing all the stfle-bits (currently four 64bit values) in the cpu_features struct, we now only store those bits, which are needed within glibc itself. Note that we have this list twice, one with original values and the other one which can be filtered with GLIBC_TUNABLES=glibc.cpu.hwcaps. Those new fields are stored in so far reserved space in cpu_features struct. Thus processes started in between the update of glibc package and we e.g. have a new ld.so and an old libc.so, won't crash. The glibc internal ifunc-resolvers would not select the best optimized variant. The users of stfle-bits are also updated: - parsing of GLIBC_TUNABLES=glibc.cpu.hwcaps - glibc internal ifunc-resolvers - __libc_ifunc_impl_list - sysconf
2025-04-29 11:28:58 +00:00
}
static inline void
init_cpu_features (struct cpu_features *cpu_features)
{
init_cpu_features_no_tunables (cpu_features);
S390: Influence hwcaps/stfle via GLIBC_TUNABLES. This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
2023-02-02 13:57:50 +00:00
TUNABLE_GET (glibc, cpu, hwcaps, tunable_val_t *, TUNABLE_CALLBACK (set_hwcaps));
}