next-20250909: selftests/arm64/gcs/basic-gcs.c:390:30: error: use of undeclared identifier 'HWCAP_GCS'
The following build warnings / errors noticed on arm64 defconfig with clang-20 and gcc-13 toolchains on the Linux next-20250909 till next-20250911 tag while building selftests/arm64.
Regression Analysis: - New regression? Yes - Reproducibility? yes
First seen on next-20250909 Good: next-20250908 Bad: next-20250909 till next-20250911
Test regression: next-20250909: selftests/arm64/gcs/basic-gcs.c:390:30: error: use of undeclared identifier 'HWCAP_GCS'
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
## Build log selftests/arm64/gcs/basic-gcs.c:390:30: error: use of undeclared identifier 'HWCAP_GCS' 390 | if (!(getauxval(AT_HWCAP) & HWCAP_GCS)) | ^ 1 error generated.
The suspected commit pointing to, kselftest/arm64/gcs: Use nolibc's getauxval() a985fe638344492727528e52416211dda1c391d5
## Source * Kernel version: 6.17.0-rc5 * Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git * Git describe: 6.17.0-rc5-next-20250911 * Git commit: 8f21d9da46702c4d6951ba60ca8a05f42870fe8f * Architectures: arm64 * Toolchains: gcc-13 and clang-20 * Kconfigs: defconfig
## Build * Build log: https://qa-reports.linaro.org/api/testruns/29827060/log_file/ * Build details: https://regressions.linaro.org/lkft/linux-next-master/next-20250909/log-pars... * Build plan: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/builds/32RzudgbCU... * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/32RzudgbCUiqGUoFtquJ9... * Kernel config: https://storage.tuxsuite.com/public/linaro/lkft/builds/32RzudgbCUiqGUoFtquJ9...
## Steps to reproduce $ tuxmake --runtime podman --target-arch arm64 \ --toolchain clang-nightly \ --kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/32RzudgbCUiqGUoFtquJ9... \ LLVM=1 LLVM_IAS=1 debugkernel dtbs dtbs-legacy headers kernel kselftest modules
-- Linaro LKFT
On Fri, Sep 12, 2025 at 12:48:47AM +0530, Naresh Kamboju wrote:
The following build warnings / errors noticed on arm64 defconfig with clang-20 and gcc-13 toolchains on the Linux next-20250909 till next-20250911 tag while building selftests/arm64.
Regression Analysis:
- New regression? Yes
- Reproducibility? yes
First seen on next-20250909 Good: next-20250908 Bad: next-20250909 till next-20250911
Test regression: next-20250909: selftests/arm64/gcs/basic-gcs.c:390:30: error: use of undeclared identifier 'HWCAP_GCS'
This will be due to Thomas Weißschuh's nolibc changes which went in during that time period and did change the program to use nolibc's getauxval, presumably that's broken with this clang version or something?
Hi Naresh,
On 2025-09-12 00:48:47+0530, Naresh Kamboju wrote:
The following build warnings / errors noticed on arm64 defconfig with clang-20 and gcc-13 toolchains on the Linux next-20250909 till next-20250911 tag while building selftests/arm64.
Regression Analysis:
- New regression? Yes
- Reproducibility? yes
First seen on next-20250909 Good: next-20250908 Bad: next-20250909 till next-20250911
Test regression: next-20250909: selftests/arm64/gcs/basic-gcs.c:390:30: error: use of undeclared identifier 'HWCAP_GCS'
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
## Build log selftests/arm64/gcs/basic-gcs.c:390:30: error: use of undeclared identifier 'HWCAP_GCS' 390 | if (!(getauxval(AT_HWCAP) & HWCAP_GCS)) | ^ 1 error generated.
The suspected commit pointing to, kselftest/arm64/gcs: Use nolibc's getauxval() a985fe638344492727528e52416211dda1c391d5
That suspicion looks correct. I am wondering a bit how this works for the other selftests which use this symbol.
Can you give this one a try:
diff --git a/tools/testing/selftests/arm64/gcs/gcs-util.h b/tools/testing/selftests/arm64/gcs/gcs-util.h index c99a6b39ac14..816b497634d6 100644 --- a/tools/testing/selftests/arm64/gcs/gcs-util.h +++ b/tools/testing/selftests/arm64/gcs/gcs-util.h @@ -26,6 +26,10 @@ struct user_gcs { }; #endif
+#ifndef HWCAP_GCS +#define HWCAP_GCS (1UL << 32) +#endif + /* Shadow Stack/Guarded Control Stack interface */ #define PR_GET_SHADOW_STACK_STATUS 74 #define PR_SET_SHADOW_STACK_STATUS 75
Hi Thomas,
On Fri, 12 Sept 2025 at 12:00, Thomas Weißschuh linux@weissschuh.net wrote:
Hi Naresh,
On 2025-09-12 00:48:47+0530, Naresh Kamboju wrote:
The following build warnings / errors noticed on arm64 defconfig with clang-20 and gcc-13 toolchains on the Linux next-20250909 till next-20250911 tag while building selftests/arm64.
Regression Analysis:
- New regression? Yes
- Reproducibility? yes
First seen on next-20250909 Good: next-20250908 Bad: next-20250909 till next-20250911
Test regression: next-20250909: selftests/arm64/gcs/basic-gcs.c:390:30: error: use of undeclared identifier 'HWCAP_GCS'
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
## Build log selftests/arm64/gcs/basic-gcs.c:390:30: error: use of undeclared identifier 'HWCAP_GCS' 390 | if (!(getauxval(AT_HWCAP) & HWCAP_GCS)) | ^ 1 error generated.
The suspected commit pointing to, kselftest/arm64/gcs: Use nolibc's getauxval() a985fe638344492727528e52416211dda1c391d5
That suspicion looks correct. I am wondering a bit how this works for the other selftests which use this symbol.
Can you give this one a try:
I have applied this patch and tested and reported build regressions got fixed.
Tested-by: Linux Kernel Functional Testing lkft@linaro.org
diff --git a/tools/testing/selftests/arm64/gcs/gcs-util.h b/tools/testing/selftests/arm64/gcs/gcs-util.h index c99a6b39ac14..816b497634d6 100644 --- a/tools/testing/selftests/arm64/gcs/gcs-util.h +++ b/tools/testing/selftests/arm64/gcs/gcs-util.h @@ -26,6 +26,10 @@ struct user_gcs { }; #endif
+#ifndef HWCAP_GCS +#define HWCAP_GCS (1UL << 32) +#endif
/* Shadow Stack/Guarded Control Stack interface */ #define PR_GET_SHADOW_STACK_STATUS 74 #define PR_SET_SHADOW_STACK_STATUS 75
-- Linaro LKFT
On Fri, Sep 12, 2025 at 08:30:08AM +0200, Thomas Weißschuh wrote:
On 2025-09-12 00:48:47+0530, Naresh Kamboju wrote:
index c99a6b39ac14..816b497634d6 100644 --- a/tools/testing/selftests/arm64/gcs/gcs-util.h +++ b/tools/testing/selftests/arm64/gcs/gcs-util.h @@ -26,6 +26,10 @@ struct user_gcs { }; #endif
+#ifndef HWCAP_GCS +#define HWCAP_GCS (1UL << 32) +#endif
We're doing that for glibc using tests because there's some unfortunate interaction between including the relevant kernel header and glibc's headers (I forget the details) which means that including the kernel header directly conflicts with something glibc is doing. For nolibc I would expect us to using the kernel's hwcap definitions?
Sep 12, 2025 12:49:58 Mark Brown broonie@kernel.org:
On Fri, Sep 12, 2025 at 08:30:08AM +0200, Thomas Weißschuh wrote:
On 2025-09-12 00:48:47+0530, Naresh Kamboju wrote:
index c99a6b39ac14..816b497634d6 100644 --- a/tools/testing/selftests/arm64/gcs/gcs-util.h +++ b/tools/testing/selftests/arm64/gcs/gcs-util.h @@ -26,6 +26,10 @@ struct user_gcs { }; #endif
+#ifndef HWCAP_GCS +#define HWCAP_GCS (1UL << 32) +#endif
We're doing that for glibc using tests because there's some unfortunate interaction between including the relevant kernel header and glibc's headers (I forget the details) which means that including the kernel header directly conflicts with something glibc is doing. For nolibc I would expect us to using the kernel's hwcap definitions?
nolibc doesn't even have its own asm/hwcap.h (or any asm/ header for that matter). So a kernel header has to be used, maybe an old one is pulled from somewhere?
(I won't have access to a development machine today anymore)
Thomas
Sep 12, 2025 12:57:15 Thomas Weißschuh linux@weissschuh.net:
Sep 12, 2025 12:49:58 Mark Brown broonie@kernel.org:
On Fri, Sep 12, 2025 at 08:30:08AM +0200, Thomas Weißschuh wrote:
On 2025-09-12 00:48:47+0530, Naresh Kamboju wrote:
index c99a6b39ac14..816b497634d6 100644 --- a/tools/testing/selftests/arm64/gcs/gcs-util.h +++ b/tools/testing/selftests/arm64/gcs/gcs-util.h @@ -26,6 +26,10 @@ struct user_gcs { }; #endif
+#ifndef HWCAP_GCS +#define HWCAP_GCS (1UL << 32) +#endif
We're doing that for glibc using tests because there's some unfortunate interaction between including the relevant kernel header and glibc's headers (I forget the details) which means that including the kernel header directly conflicts with something glibc is doing. For nolibc I would expect us to using the kernel's hwcap definitions?
nolibc doesn't even have its own asm/hwcap.h (or any asm/ header for that matter). So a kernel header has to be used, maybe an old one is pulled from somewhere?
The Makefile does *not* use -nostdinc, so the nolibc program probably finds the toolchain's glibc asm/hwcap.h. There also doesn't seem to be a static arm64 hwcap header in tools/include in the first place. I am still wondering how this works for the other tests.
Thomas
On Fri, Sep 12, 2025 at 01:07:58PM +0200, Thomas Weißschuh wrote:
The Makefile does *not* use -nostdinc, so the nolibc program probably finds the toolchain's glibc asm/hwcap.h. There also doesn't seem to be a static arm64 hwcap header in tools/include in the first place. I am still wondering how this works for the other tests.
make headers_install puts a copy in usr/include, probably we just need to include that in the include path.
linux-kselftest-mirror@lists.linaro.org
-
Mark Brown -
Naresh Kamboju -
Thomas Weißschuh