Received: by 2002:a05:7412:b10a:b0:f3:1519:9f41 with SMTP id az10csp3024232rdb; Mon, 4 Dec 2023 14:33:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IEl8X4ysUBO6KB2Y5h7AUhd0MeByjYuI1+lQeBYhISHBk/0H2Qz/5bQEL5ImgGmXwVf71Bi X-Received: by 2002:a17:902:c155:b0:1d0:5af0:1fe with SMTP id 21-20020a170902c15500b001d05af001femr2295518plj.40.1701729205851; Mon, 04 Dec 2023 14:33:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701729205; cv=none; d=google.com; s=arc-20160816; b=tGwd+iBJfkDBaECQSd5gXbk/Uw5Sdv8z9+qKFNORyCEaLlbvFAR9qJBwMVHyFjWkj4 IxnmBVB4LFOQysbpkAgLfr+S4NvybCLP5EoQHnflynkSgT3AUCKmHxLIgf93OxMkFSxk 8fgK5C5iOw04tvyiaqx8YtiEfYoj7jbILxPD4qwanozn19ZClLP+Bae0Qp2b0wxwo1RW Nho+uHTRifK6D4l9uweVZwbtTpwGtMqnCAPmZy+q7E3eX/CLBekBj1GqBXGIx/yNMro0 9G30gIuicWolFu1ZHovBxyc5VmPGhu4YBAuhgoZMZNz7eco7D1CMurFiIJ33+q8RrO74 FzSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=eIKaWa9Kr8Snm3xfCzMHqFuMoEv5S0tvB8mKMOsVGP4=; fh=3IVl1FFYEhnAdc103SFjZsiLnLoKutN1TGjpjQXhqAU=; b=yNRejmMAkZrUMdSOVBeYNtiSBkdsihHfnWheUU0DbiznywZxpi+eplHdKZDP9HyHgQ D4Q+/8aK4lH5X3rL3DHgVHdZI2l2r9HTm2EyNg/3oFc+NxQLbcyq4OlDpxC8Kwj6mBsH /OutJG5lxci97rtGKpzj6W0gmAd8FiiFolptm2roD10y4btVIX0bUGelGOlF0j1QxVeL mvbMykFKwb1ERXagDAYmqEV/Satz5y+3yJPUIwbubLoa25xouy3zbdNDO9p5fd/YFOI/ ejpQDZHXaO0u66uruOp54EscTfzBMM4iq4nuFtPPDQyI7t8Y3/BwRJiH5InW9L+jMje3 LJSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=B9DIk1Nk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id 20-20020a170902c25400b001cfc2cfe858si7615156plg.489.2023.12.04.14.33.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 14:33:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=B9DIk1Nk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 91E2D80AEB07; Mon, 4 Dec 2023 14:33:24 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229925AbjLDWdO (ORCPT + 99 others); Mon, 4 Dec 2023 17:33:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229668AbjLDWdN (ORCPT ); Mon, 4 Dec 2023 17:33:13 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4AFFA9 for ; Mon, 4 Dec 2023 14:33:19 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5180C433C7; Mon, 4 Dec 2023 22:33:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701729199; bh=WfQFLken07ph4TbDrqs4sN/0bpMdipRIiq7jjcv/vSk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=B9DIk1Nk/8NJjq/KZyxdt6AZYF+a6MSTTeH3x79nl/D1W9vijfBDTfmP7H94tTiNP oXn+NHnSRRl+31vMtcQSmZ4EILPBFkjoel3Taq0gXeIpLBTCK4Moa0wFdn3GUpc7/r UHH9hUqAxxQxA5w9h+6IIfGTa6wGs6FJEV3X9tDeBkltGRtdtNpY+YMzIH+2htoQS+ +Raf1k8khKq6vkFLdInzannJfWydc1XUIZn+0AaO8VL2DFSZtfOmRi1sc5XCC5k+rw RxdlSO7r4xsyRTuXfWfY4RvD9cdbA1A78He44wKqkD37D9sY1/5tZx1Z4sRk04eE+A CI248su1mCbRA== Date: Mon, 4 Dec 2023 15:33:17 -0700 From: Nathan Chancellor To: Naresh Kamboju Cc: clang-built-linux , Linux ARM , open list , Linux Regressions , lkft-triage@lists.linaro.org, Russell King - ARM Linux , Arnd Bergmann , Nick Desaulniers , Sylvestre Ledru Subject: Re: clang-nightly: vdso/compat_gettimeofday.h:152:15: error: instruction variant requires ARMv6 or later Message-ID: <20231204223317.GA2053629@dev-arch.thelio-3990X> References: <20231204181304.GA2043538@dev-arch.thelio-3990X> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231204181304.GA2043538@dev-arch.thelio-3990X> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 04 Dec 2023 14:33:24 -0800 (PST) On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote: > 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 > > > > > > 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)); > > | ^ > > :1:2: note: instantiated into assembly here > > 1 | mov r4, r1 > > | ^ > > In file included from :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. 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 require use of the integrated assembler, which means we can add '-mcpu=generic' (the default in LLVM for those files based on my debugging) to those files 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 ?= $(CC) CC_COMPAT += --target=arm-linux-gnueabi +# Some distributions (such as Debian) change the default CPU for the +# 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 += -mcpu=generic else CC_COMPAT ?= $(CROSS_COMPILE_COMPAT)gcc endif The failures for all the ARCH=arm configurations appear to be much more difficult to fix because the default CPU value changes based on the '-march' value, which basically means that we would have to hardcode LLVM's default CPU logic into the kernel's Makefile, which is just not maintainable in my opinion. Just doing a multi_v7_defconfig build of arch/arm/ shows the value returned from ARM::getARMCPUForArch() in llvm/lib/TargetParser/ARMTargetParser.cpp can vary between "arm7tdmi" or "generic". Supplying '-mcpu=generic' explicitly won't work with LLVM_IAS=0 because GNU as does not support it and clang just happily passes it along, even though it does not do that in the implicit default case. Sylvestre, I strongly believe you should consider reverting that change 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=arm-linux-gnueabi -march=armv7-a' won't actually target ARMv7: $ echo 'int main(void) { asm("dsb"); return 0; }' | \ clang --target=arm-linux-gnueabi -march=armv7-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=arm-linux-gnueabi -march=armv7-a \ -x c -c -o /dev/null -v - ... "/bin/clang-18" -cc1 -triple armv5e-unknown-linux-gnueabi ... ... Cheers, Nathan