Hi Naresh,
On Mon, Dec 04, 2023 at 05:33:26PM +0530, Naresh Kamboju wrote:
Following build errors noticed on Linux next-20231204 tag with clang-nightly for arm and arm64.
## Test Regressions (compared to next-20231201)
arm64, build
- clang-nightly-defconfig
- clang-nightly-defconfig-40bc7ee5
- clang-nightly-lkftconfig
- clang-nightly-lkftconfig-kselftest
arm, build
- clang-nightly-allnoconfig
- clang-nightly-axm55xx_defconfig
- clang-nightly-bcm2835_defconfig
- clang-nightly-clps711x_defconfig
- clang-nightly-defconfig
- clang-nightly-exynos_defconfig
- clang-nightly-imx_v6_v7_defconfig
- clang-nightly-keystone_defconfig
- clang-nightly-lkftconfig
- clang-nightly-lkftconfig-kselftest
- clang-nightly-omap2plus_defconfig
- clang-nightly-pxa910_defconfig
- clang-nightly-s3c6400_defconfig
- clang-nightly-s5pv210_defconfig
- clang-nightly-sama5_defconfig
- clang-nightly-shmobile_defconfig
- clang-nightly-tinyconfig
- clang-nightly-u8500_defconfig
- clang-nightly-vexpress_defconfig
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Build log on arm64:
In file included from lib/vdso/gettimeofday.c:5: In file included from include/vdso/datapage.h:135: arch/arm64/include/asm/vdso/compat_gettimeofday.h:152:15: error: instruction variant requires ARMv6 or later 152 | asm volatile("mov %0, %1" : "=r"(ret) : "r"(_vdso_data)); | ^ <inline asm>:1:2: note: instantiated into assembly here 1 | mov r4, r1 | ^ In file included from <built-in>:3: lib/vdso/gettimeofday.c:139:3: error: invalid instruction 139 | smp_rmb(); | ^
Build log on arm:
In file included from arch/arm/vfp/vfpmodule.c:23: arch/arm/include/asm/cp15.h:101:2: error: instruction requires: data-barriers 101 | isb(); | ^
This is caused by a change to Debian's LLVM that changes the internal defaults of the arm-linux-gnueabi and arm-linux-gnueabihf tuples:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/907baf024b9a5...
We use arm-linux-gnueabi for the kernel (see scripts/Makefile.clang) so now we have a hardcoded armv5te CPU, even if we are building for armv7 or such.
I am still investigating into what (if anything) can be done to resolve this on the kernel side. We could potentially revert commit ddc72c9659b5 ("kbuild: clang: do not use CROSS_COMPILE for target triple") but I am not sure that will save us from that change, as tuxmake's CROSS_COMPILE=arm-linux-gnueabihf will cause us to have an armv7 CPU even though we may not be building for armv7.
Cheers, Nathan