Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: clang-built-linux <llvm@lists.linux.dev>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>,
	Linux Regressions <regressions@lists.linux.dev>,
	lkft-triage@lists.linaro.org,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: clang-nightly: vdso/compat_gettimeofday.h:152:15: error: instruction variant requires ARMv6 or later
Date: Mon, 4 Dec 2023 11:13:04 -0700	[thread overview]
Message-ID: <20231204181304.GA2043538@dev-arch.thelio-3990X> (raw)
In-Reply-To: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>

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/907baf024b9a5a1626893d9e731b6c79ccf45c87

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-12-04 18:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-04 12:03 clang-nightly: vdso/compat_gettimeofday.h:152:15: error: instruction variant requires ARMv6 or later Naresh Kamboju
2023-12-04 18:13 ` Nathan Chancellor [this message]
2023-12-04 18:26   ` Russell King (Oracle)
2023-12-04 19:59     ` Nathan Chancellor
2023-12-04 22:33   ` Nathan Chancellor
2023-12-04 22:42     ` Sylvestre Ledru
2023-12-04 22:51       ` Nathan Chancellor
2023-12-05  6:34     ` Arnd Bergmann
2023-12-05 15:04       ` Nathan Chancellor
2023-12-05 15:13         ` Sylvestre Ledru
2023-12-05 17:21           ` Nathan Chancellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231204181304.GA2043538@dev-arch.thelio-3990X \
    --to=nathan@kernel.org \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lkft-triage@lists.linaro.org \
    --cc=llvm@lists.linux.dev \
    --cc=naresh.kamboju@linaro.org \
    --cc=ndesaulniers@google.com \
    --cc=regressions@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox