From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E5F52C4167B for ; Tue, 5 Dec 2023 17:22:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ElA+kcQ363A8Cub/tYRRhgkv1hWFjT7u33W9qLPsEDQ=; b=RL6xwY4OFxuYbI PwsYxua5ZhSd1gpecJWhS7f/PnlGvnPRvogNbc2soHBOiuvpPp3vT4P+bePs+PGPE5IrImyDeolvc LxCYNTPsiq6ce4aP0+Uhv7R441Fp6xpv7Q6MbvYC8GptdVTf/kf94zmZ2CmeVJF01KjEIPXMHaCgH tmAp8/zy892uyZJtdDg+ZeU9PIjt7nVlMZnDAoOeJKbQ5GTASwydEgdesMTdNPjwPfA597Y9HvhSV MHgiIIj0uT3CC+0KVZFjjTomFv6X7VkYyqAIx+fXyk1U5K0faBcIAnxJwwbven5/uZ2kX9faJ5Ypi Q+CQQO4W7bWgIaqEb5NA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rAZ77-0081Ng-2W; Tue, 05 Dec 2023 17:21:41 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rAZ74-0081LQ-0e for linux-arm-kernel@lists.infradead.org; Tue, 05 Dec 2023 17:21:40 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id E51C4B81AAA; Tue, 5 Dec 2023 17:21:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9187CC433C8; Tue, 5 Dec 2023 17:21:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701796896; bh=qQhFD5km7iam6ql60v2yvQ1cEjm2HjSDpoeTEUpsrRk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SVvOED5TQV7w6aix5CSUmAgTtyEnO62rBkggKujtvoSWaIHBF/KbD6e14Hk2JPqz6 3jXmvJUZek6eE5B+WZSrqApTnf1DIlnTzGjhSMK2NoICzENS/IKes8mJEFE1Wxoha8 qR+IyfxpQ1Faqi/sTdJ2HjSERHq0z1khOYRmfF8y/go/CicJFNQrVVx8vTzPsfDurZ 2lWey7UGuMC2z1W9gPskSHANViFPfSn8Dd/DWwCQIRZc0AYMthmCCwGeREnKHRcVgp nlIIWKz6cR+Tc2xLEuqggbwBVW7MLF1jZm0aBfqAfPSPj7M9cRhbPBuUIV2Uw4xwO5 4KG2CE7WvT/ww== Date: Tue, 5 Dec 2023 10:21:33 -0700 From: Nathan Chancellor To: Sylvestre Ledru Cc: Arnd Bergmann , Naresh Kamboju , clang-built-linux , Linux ARM , open list , Linux Regressions , lkft-triage@lists.linaro.org, Russell King , Nick Desaulniers , Matthias Klose Subject: Re: clang-nightly: vdso/compat_gettimeofday.h:152:15: error: instruction variant requires ARMv6 or later Message-ID: <20231205172133.GA462711@dev-arch.thelio-3990X> References: <20231204181304.GA2043538@dev-arch.thelio-3990X> <20231204223317.GA2053629@dev-arch.thelio-3990X> <36a25113-731c-4b28-a695-f3fbb0996d6e@app.fastmail.com> <20231205150417.GA349053@dev-arch.thelio-3990X> <3523ca62-be8b-4b08-8d0c-5b97ece9aad8@debian.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3523ca62-be8b-4b08-8d0c-5b97ece9aad8@debian.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231205_092138_513137_A3B22591 X-CRM114-Status: GOOD ( 44.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Dec 05, 2023 at 04:13:29PM +0100, Sylvestre Ledru wrote: > Le 05/12/2023 =E0 16:04, Nathan Chancellor a =E9crit=A0: > > On Tue, Dec 05, 2023 at 07:34:40AM +0100, Arnd Bergmann wrote: > > > On Mon, Dec 4, 2023, at 23:33, Nathan Chancellor wrote: > > > > On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote: > > > > = > > > > > I am still investigating into what (if anything) can be done to r= esolve > > > > > 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=3Darm-linux-gnueabihf will cause us to ha= ve an > > > > > armv7 CPU even though we may not be building for armv7. > > > > = > > > > Okay, this is a pretty awful situation the more I look into it :( > > > > = > > > > The arm64 compat vDSO build is easy enough to fix because we requir= e use > > > > of the integrated assembler, which means we can add '-mcpu=3Dgeneri= c' (the > > > > default in LLVM for those files based on my debugging) to those fil= es > > > > and be done with it: > > > > = > > > > diff --git a/arch/arm64/kernel/vdso32/Makefile > > > > b/arch/arm64/kernel/vdso32/Makefile > > > > index 1f911a76c5af..5f5cb722cfc2 100644 > > > > --- a/arch/arm64/kernel/vdso32/Makefile > > > > +++ b/arch/arm64/kernel/vdso32/Makefile > > > > @@ -9,6 +9,10 @@ include $(srctree)/lib/vdso/Makefile > > > > ifeq ($(CONFIG_CC_IS_CLANG), y) > > > > CC_COMPAT ?=3D $(CC) > > > > CC_COMPAT +=3D --target=3Darm-linux-gnueabi > > > > +# Some distributions (such as Debian) change the default CPU for t= he > > > > +# arm-linux-gnueabi target triple, which can break the build. > > > > Explicitly set > > > > +# the CPU to generic, which is the default for Linux in LLVM. > > > > +CC_COMPAT +=3D -mcpu=3Dgeneric > > > > else > > > > CC_COMPAT ?=3D $(CROSS_COMPILE_COMPAT)gcc > > > > endif > > > = > > > I'm still trying to follow what is actually going on. I > > > see that we pass > > > = > > > VDSO_CAFLAGS +=3D -march=3Darmv8-a > > > = > > > which is meant to tell the compiler that we want it to > > > use ARMv8 compatible instructions. Is the problem that > > > clang ignores this flag, or do we not pass it correctly? > > > = > > > I would have expected -march=3Darmv8-a to be better than > > > -mcpu=3Dgeneric here, as it allows the compiler to use > > > a wider set of instructions that is still guaranteed to > > > be available on everything it will run on. > > = > > I should have made it clearer in that message that adding > > '-mcpu=3Dgeneric' was only to avoid the logic added by that Debian LLVM > > change, not because I believe the kernel is doing something incorrectly > > now. From what I could tell following through LLVM's code, '-march=3D' > > determines the default CPU, which is then used to further inform the > > full target triple and by overriding the CPU where that patch did, it > > was just blowing away the user's request. By providing an '-mcpu=3D' > > option explicitly, it would avoid the default selection logic and we > > would get what we asked for. > > = > > > > Sylvestre, I strongly believe you should consider reverting that ch= ange > > > > or give us some compiler flag that allows us to fallback to upstream > > > > LLVM's default CPU selection logic. I think that hardcoding Debian's > > > > architecture defintions based on the target triple into the compiler > > > > could cause issues for other projects as well. For example, > > > > '--target=3Darm-linux-gnueabi -march=3Darmv7-a' won't actually targ= et ARMv7: > > > > = > > > > $ echo 'int main(void) { asm("dsb"); return 0; }' | \ > > > > clang --target=3Darm-linux-gnueabi -march=3Darmv7-a \ > > > > -x c -c -o /dev/null -v - > > > > ... > > > > "/usr/bin/clang-17" -cc1 -triple armv7-unknown-linux-gnueabi ... > > > > ... > > > > = > > > > vs. > > > > = > > > > $ echo 'int main(void) { asm("dsb"); return 0; }' | \ > > > > clang --target=3Darm-linux-gnueabi -march=3Darmv7-a \ > > > > -x c -c -o /dev/null -v - > > > > ... > > > > "/bin/clang-18" -cc1 -triple armv5e-unknown-linux-gnueab= i ... > > > > ... > > > = > > > Right, the kernel definitely relies on -march=3D taking > > > precedence over the default CPU, the same way that we > > > tell the compiler to pick a non-default endianess or ABI. > > = > > Agreed, I have yet to test the new version of the patch but I see you > > and Ard have given input on it, so hopefully it does not have any > > problems like this. > = > Matthias, as cc, pushed a potential fix for debian/ubuntu packages! > https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/01a06b481e= 5a2610c7387149b58978c3ec281f2c Thanks, that version survives my basic testing of both ARCH=3Darm and ARCH=3Darm64 defconfig. I'll holler if our full matrix explodes later (we have another regression in LLVM right now so we are not testing the snapshots daily at the moment). Cheers, Nathan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel