Message ID | 20230624184055.3000636-8-kernel@xen0n.name |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp6553914vqr; Sat, 24 Jun 2023 11:59:06 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ590/CXSv711wTF0440Z80QAfeyIUd//KsRXLAJHiplYuyYr4zVuLunm6xmDGByS6EV2tFd X-Received: by 2002:a5d:9d4f:0:b0:782:6364:3784 with SMTP id k15-20020a5d9d4f000000b0078263643784mr5511486iok.0.1687633146660; Sat, 24 Jun 2023 11:59:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687633146; cv=none; d=google.com; s=arc-20160816; b=EQQhuPkUvQsWCAJzUKpjtR2RUzTiRpEEozD3ggFo90Z8DNPlpDiVcjxGk/Oa7PfMcL 9fToaplssv5q7x7rZ+D4RDSJEeo2nsvapKiyAprwCBniJjeYp6fuCdGyKJOrfbn80QEV m8Orfbm67JJiIjNDUx5gWj1FL47wslTkn+1wzJ/o+AJ07BqPlsCkY8JEBgBH5mjuY2oy QL6Z39ywakeUPQGvPCWNLBXD5kzzj/IPHpVh/Mo+FCHUh+Zj39UIkT4ovf3BOGcj72j5 G8NOX8jZ+/s54Odt0+xFvPJXFVNQpPeTlGe4aVP2SUsTdaN0R1XmFLjzzwUNwx7ni8sn 2dEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=UWXb1Q+4zhaMMR8NYs0zWDlrDmFt1hQCTNcqsh9PeRs=; fh=dOptu1ihZdKkZ8ajFex7p+VOwkwvZgrA6cQy2X6s+EM=; b=SditBrgzrV9b4vD+63kmsmfZDcZsRxVLPwF8+tcDjbWODLgYJIrOsHgY4gj2w7DxnR mPJRQDpvix6l3WsCZ62yp5BD/rO7JJgnNCCLzw//jr5nmXJvj4Lbx9u8WUF6aCQ4IrSd ACsHTOBvFtOe+SIlN8X/pN5bJqOVj6YDZgEKnqrV7QscdIAjDUwFsTjDDoEQYbCgGn2A adksIed7+7LRSK1v6iYrDxiDblSb2ILyb4lur3HtbNhLZOYCrWrQYHJjXCdf939I8ew9 MQNBK+XMhnDE8v5WMhfHSogHmyv/S0rCl5rs8/T8a+MBeYifLtz6Yas2+wT8rvKqQviE p/qA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@xen0n.name header.s=mail header.b=FJtLR5X9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q34-20020a17090a1b2500b002587b0434d7si1990530pjq.132.2023.06.24.11.58.54; Sat, 24 Jun 2023 11:59:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@xen0n.name header.s=mail header.b=FJtLR5X9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233233AbjFXSm4 (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Sat, 24 Jun 2023 14:42:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233219AbjFXSmt (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 24 Jun 2023 14:42:49 -0400 Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB7042699; Sat, 24 Jun 2023 11:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1687632140; bh=0Tq7EFJUUQOAtspH6l1egJDQ+7z8Kts6U1eCmQuulT0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FJtLR5X9id4V7kryXwZrL369m5ZrY688s67Lk5G4iVzV+IqTKZbXuEWqWIXac+jYi lkDPwriZygD8MFQetGr4JJPxIlyw0AvOCyAFl3xHVDLRG8kJO3Q8r1htcf9cRxcODd URv4KRbKKhhsgdfmAkRmO6y53nzP0Mac1lNjgiKA= Received: from ld50.lan (unknown [101.88.25.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 1AF6960164; Sun, 25 Jun 2023 02:42:20 +0800 (CST) From: WANG Xuerui <kernel@xen0n.name> To: Huacai Chen <chenhuacai@kernel.org> Cc: WANG Rui <wangrui@loongson.cn>, Xi Ruoyao <xry111@xry111.site>, loongarch@lists.linux.dev, linux-kbuild@vger.kernel.org, llvm@lists.linux.dev, linux-kernel@vger.kernel.org, WANG Xuerui <git@xen0n.name> Subject: [PATCH v2 7/9] LoongArch: Tweak CFLAGS for Clang compatibility Date: Sun, 25 Jun 2023 02:40:53 +0800 Message-Id: <20230624184055.3000636-8-kernel@xen0n.name> X-Mailer: git-send-email 2.40.0 In-Reply-To: <20230624184055.3000636-1-kernel@xen0n.name> References: <20230624184055.3000636-1-kernel@xen0n.name> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769611614385669279?= X-GMAIL-MSGID: =?utf-8?q?1769611614385669279?= |
Series |
LoongArch: Preliminary ClangBuiltLinux enablement
|
|
Commit Message
WANG Xuerui
June 24, 2023, 6:40 p.m. UTC
From: WANG Xuerui <git@xen0n.name> Now the arch code is mostly ready for LLVM/Clang consumption, it is time to re-organize the CFLAGS a little to actually enable the LLVM build. In particular, -mexplicit-relocs and -mdirect-extern-access are not necessary nor supported on Clang; feature detection via cc-option would not work, because that way the broken combo of "new GNU as + old GCC" would seem to get "fixed", but actually produce broken kernels. Explicitly depending on CONFIG_CC_IS_CLANG is thus necessary to not regress UX for those building their own kernels. A build with !RELOCATABLE && !MODULE is confirmed working within a QEMU environment; support for the two features are currently blocked on LLVM/Clang, and will come later. Signed-off-by: WANG Xuerui <git@xen0n.name> --- arch/loongarch/Makefile | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Comments
On Sun, 2023-06-25 at 02:40 +0800, WANG Xuerui wrote: > From: WANG Xuerui <git@xen0n.name> > > Now the arch code is mostly ready for LLVM/Clang consumption, it is > time > to re-organize the CFLAGS a little to actually enable the LLVM build. > > In particular, -mexplicit-relocs and -mdirect-extern-access are not > necessary nor supported on Clang; feature detection via cc-option > would > not work, because that way the broken combo of "new GNU as + old GCC" > would seem to get "fixed", but actually produce broken kernels. > Explicitly depending on CONFIG_CC_IS_CLANG is thus necessary to not > regress UX for those building their own kernels. > > A build with !RELOCATABLE && !MODULE is confirmed working within a > QEMU > environment; support for the two features are currently blocked on > LLVM/Clang, and will come later. > > Signed-off-by: WANG Xuerui <git@xen0n.name> > --- > arch/loongarch/Makefile | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile > index 366771016b99..82c619791a63 100644 > --- a/arch/loongarch/Makefile > +++ b/arch/loongarch/Makefile > @@ -51,7 +51,9 @@ LDFLAGS_vmlinux += -static -n > -nostdlib > > # When the assembler supports explicit relocation hint, we must use it. > # GCC may have -mexplicit-relocs off by default if it was built with an old > -# assembler, so we force it via an option. > +# assembler, so we force it via an option. For LLVM/Clang the desired behavior > +# is the default Actually -mdirect-extern-access is also a part of the desired behavior. Though it's not strictly needed, it is a micro-optimization to avoid unnecessary GOT accesses. Maybe with Clang the LTO pass can optimize them away but I'm not sure. Ok with the flags change (for now) but the comment can be more accurate. > , and the flag is not supported, so don't pass it if Clang is > +# being used. > # > # When the assembler does not supports explicit relocation hint, we can't use > # it. Disable it if the compiler supports it. > @@ -61,8 +63,10 @@ LDFLAGS_vmlinux += -static -n -nostdlib > # combination of a "new" assembler and "old" compiler is not supported. Either > # upgrade the compiler or downgrade the assembler. > ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS > +ifndef CONFIG_CC_IS_CLANG > cflags-y += -mexplicit-relocs > KBUILD_CFLAGS_KERNEL += -mdirect-extern-access > +endif > else > cflags-y += $(call cc-option,-mno-explicit-relocs) > KBUILD_AFLAGS_KERNEL += -Wa,-mla-global-with-pcrel
Hi, Ruoyao, On Sun, Jun 25, 2023 at 2:42 AM WANG Xuerui <kernel@xen0n.name> wrote: > > From: WANG Xuerui <git@xen0n.name> > > Now the arch code is mostly ready for LLVM/Clang consumption, it is time > to re-organize the CFLAGS a little to actually enable the LLVM build. > > In particular, -mexplicit-relocs and -mdirect-extern-access are not > necessary nor supported on Clang; feature detection via cc-option would > not work, because that way the broken combo of "new GNU as + old GCC" > would seem to get "fixed", but actually produce broken kernels. > Explicitly depending on CONFIG_CC_IS_CLANG is thus necessary to not > regress UX for those building their own kernels. > > A build with !RELOCATABLE && !MODULE is confirmed working within a QEMU > environment; support for the two features are currently blocked on > LLVM/Clang, and will come later. > > Signed-off-by: WANG Xuerui <git@xen0n.name> > --- > arch/loongarch/Makefile | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile > index 366771016b99..82c619791a63 100644 > --- a/arch/loongarch/Makefile > +++ b/arch/loongarch/Makefile > @@ -51,7 +51,9 @@ LDFLAGS_vmlinux += -static -n -nostdlib > > # When the assembler supports explicit relocation hint, we must use it. > # GCC may have -mexplicit-relocs off by default if it was built with an old > -# assembler, so we force it via an option. > +# assembler, so we force it via an option. For LLVM/Clang the desired behavior > +# is the default, and the flag is not supported, so don't pass it if Clang is > +# being used. > # > # When the assembler does not supports explicit relocation hint, we can't use > # it. Disable it if the compiler supports it. > @@ -61,8 +63,10 @@ LDFLAGS_vmlinux += -static -n -nostdlib > # combination of a "new" assembler and "old" compiler is not supported. Either > # upgrade the compiler or downgrade the assembler. > ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS > +ifndef CONFIG_CC_IS_CLANG > cflags-y += -mexplicit-relocs > KBUILD_CFLAGS_KERNEL += -mdirect-extern-access > +endif I prefer to drop CONFIG_CC_IS_CLANG and use cflags-y += $(call cc-option,-mexplicit-relocs) KBUILD_CFLAGS_KERNEL += $(call cc-option,-mdirect-extern-access) Then Patch-6 can be merged in this. What's your opinion? Huacai > else > cflags-y += $(call cc-option,-mno-explicit-relocs) > KBUILD_AFLAGS_KERNEL += -Wa,-mla-global-with-pcrel > -- > 2.40.0 >
On 2023/6/25 10:13, Huacai Chen wrote: > Hi, Ruoyao, > > On Sun, Jun 25, 2023 at 2:42 AM WANG Xuerui <kernel@xen0n.name> wrote: >> >> From: WANG Xuerui <git@xen0n.name> >> >> Now the arch code is mostly ready for LLVM/Clang consumption, it is time >> to re-organize the CFLAGS a little to actually enable the LLVM build. >> >> In particular, -mexplicit-relocs and -mdirect-extern-access are not >> necessary nor supported on Clang; feature detection via cc-option would >> not work, because that way the broken combo of "new GNU as + old GCC" >> would seem to get "fixed", but actually produce broken kernels. >> Explicitly depending on CONFIG_CC_IS_CLANG is thus necessary to not >> regress UX for those building their own kernels. >> >> A build with !RELOCATABLE && !MODULE is confirmed working within a QEMU >> environment; support for the two features are currently blocked on >> LLVM/Clang, and will come later. >> >> Signed-off-by: WANG Xuerui <git@xen0n.name> >> --- >> arch/loongarch/Makefile | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile >> index 366771016b99..82c619791a63 100644 >> --- a/arch/loongarch/Makefile >> +++ b/arch/loongarch/Makefile >> @@ -51,7 +51,9 @@ LDFLAGS_vmlinux += -static -n -nostdlib >> >> # When the assembler supports explicit relocation hint, we must use it. >> # GCC may have -mexplicit-relocs off by default if it was built with an old >> -# assembler, so we force it via an option. >> +# assembler, so we force it via an option. For LLVM/Clang the desired behavior >> +# is the default, and the flag is not supported, so don't pass it if Clang is >> +# being used. >> # >> # When the assembler does not supports explicit relocation hint, we can't use >> # it. Disable it if the compiler supports it. >> @@ -61,8 +63,10 @@ LDFLAGS_vmlinux += -static -n -nostdlib >> # combination of a "new" assembler and "old" compiler is not supported. Either >> # upgrade the compiler or downgrade the assembler. >> ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS >> +ifndef CONFIG_CC_IS_CLANG >> cflags-y += -mexplicit-relocs >> KBUILD_CFLAGS_KERNEL += -mdirect-extern-access >> +endif > I prefer to drop CONFIG_CC_IS_CLANG and use > cflags-y += $(call cc-option,-mexplicit-relocs) > KBUILD_CFLAGS_KERNEL += $(call cc-option,-mdirect-extern-access) > > Then Patch-6 can be merged in this. > > What's your opinion? FYI: with this approach the build no longer instantly dies with binutils 2.40 + gcc 12.3, but there are also tons of warnings that say the model attribute is being ignored. I checked earlier discussions and this means modules are silently broken at runtime, which is not particularly good UX. But after more thought, I find it possible to not regress UX nor explicitly check for Clang: the special point about Clang is that it emits explicit relocs *without* support for the CLI -mexplicit-relocs flag. So assuming: * CC_HAS_EXPLICIT_RELOCS means "-mexplicit-relocs" is supported by $CC, * CC_EMITS_EXPLICIT_RELOCS means explicit relocs are emitted by $CC, with -mexplicit-relocs in CFLAGS if supported, We then have: * gcc 12.x: !CC_HAS_EXPLICIT_RELOCS && !CC_EMITS_EXPLICIT_RELOCS * gcc 13.x: CC_HAS_EXPLICIT_RELOCS && CC_EMITS_EXPLICIT_RELOCS * clang: !CC_HAS_EXPLICIT_RELOCS && CC_EMITS_EXPLICIT_RELOCS So in this case (inside the AS_HAS_EXPLICIT_RELOCS=y block), as long as CC_EMITS_EXPLICIT_RELOCS we are okay. We can $(error) out in the first case and provide helpful diagnostics too. What do you people think about this alternative approach?
On Sun, 2023-06-25 at 15:16 +0800, WANG Xuerui wrote: > On 2023/6/25 10:13, Huacai Chen wrote: > > Hi, Ruoyao, > > > > On Sun, Jun 25, 2023 at 2:42 AM WANG Xuerui <kernel@xen0n.name> wrote: > > > > > > From: WANG Xuerui <git@xen0n.name> > > > > > > Now the arch code is mostly ready for LLVM/Clang consumption, it is time > > > to re-organize the CFLAGS a little to actually enable the LLVM build. > > > > > > In particular, -mexplicit-relocs and -mdirect-extern-access are not > > > necessary nor supported on Clang; feature detection via cc-option would > > > not work, because that way the broken combo of "new GNU as + old GCC" > > > would seem to get "fixed", but actually produce broken kernels. > > > Explicitly depending on CONFIG_CC_IS_CLANG is thus necessary to not > > > regress UX for those building their own kernels. > > > > > > A build with !RELOCATABLE && !MODULE is confirmed working within a QEMU > > > environment; support for the two features are currently blocked on > > > LLVM/Clang, and will come later. > > > > > > Signed-off-by: WANG Xuerui <git@xen0n.name> > > > --- > > > arch/loongarch/Makefile | 6 +++++- > > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile > > > index 366771016b99..82c619791a63 100644 > > > --- a/arch/loongarch/Makefile > > > +++ b/arch/loongarch/Makefile > > > @@ -51,7 +51,9 @@ LDFLAGS_vmlinux += -static -n -nostdlib > > > > > > # When the assembler supports explicit relocation hint, we must use it. > > > # GCC may have -mexplicit-relocs off by default if it was built with an old > > > -# assembler, so we force it via an option. > > > +# assembler, so we force it via an option. For LLVM/Clang the desired behavior > > > +# is the default, and the flag is not supported, so don't pass it if Clang is > > > +# being used. > > > # > > > # When the assembler does not supports explicit relocation hint, we can't use > > > # it. Disable it if the compiler supports it. > > > @@ -61,8 +63,10 @@ LDFLAGS_vmlinux += -static -n -nostdlib > > > # combination of a "new" assembler and "old" compiler is not supported. Either > > > # upgrade the compiler or downgrade the assembler. > > > ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS > > > +ifndef CONFIG_CC_IS_CLANG > > > cflags-y += -mexplicit-relocs > > > KBUILD_CFLAGS_KERNEL += -mdirect-extern-access > > > +endif > > I prefer to drop CONFIG_CC_IS_CLANG and use > > cflags-y += $(call cc-option,-mexplicit-relocs) > > KBUILD_CFLAGS_KERNEL += $(call cc-option,-mdirect-extern-access) > > > > Then Patch-6 can be merged in this. > > > > What's your opinion? > > FYI: with this approach the build no longer instantly dies with binutils > 2.40 + gcc 12.3, but there are also tons of warnings that say the model > attribute is being ignored. I checked earlier discussions and this means > modules are silently broken at runtime, which is not particularly good UX. We can add #if defined(MODULE) && !__has_attribute(model) # error some fancy error message #endif into percpu.h to error out in this case. It had been in my earlier drafts of explicit relocs patches, but we dropped it because there was no such configuration (unless a snapshot of development GCC is used, and using such a snapshot is never supported IIUC).
On 2023/6/25 15:36, Xi Ruoyao wrote: > On Sun, 2023-06-25 at 15:16 +0800, WANG Xuerui wrote: >> On 2023/6/25 10:13, Huacai Chen wrote: >>> Hi, Ruoyao, >>> >>> On Sun, Jun 25, 2023 at 2:42 AM WANG Xuerui <kernel@xen0n.name> wrote: >>>> >>>> From: WANG Xuerui <git@xen0n.name> >>>> >>>> Now the arch code is mostly ready for LLVM/Clang consumption, it is time >>>> to re-organize the CFLAGS a little to actually enable the LLVM build. >>>> >>>> In particular, -mexplicit-relocs and -mdirect-extern-access are not >>>> necessary nor supported on Clang; feature detection via cc-option would >>>> not work, because that way the broken combo of "new GNU as + old GCC" >>>> would seem to get "fixed", but actually produce broken kernels. >>>> Explicitly depending on CONFIG_CC_IS_CLANG is thus necessary to not >>>> regress UX for those building their own kernels. >>>> >>>> A build with !RELOCATABLE && !MODULE is confirmed working within a QEMU >>>> environment; support for the two features are currently blocked on >>>> LLVM/Clang, and will come later. >>>> >>>> Signed-off-by: WANG Xuerui <git@xen0n.name> >>>> --- >>>> arch/loongarch/Makefile | 6 +++++- >>>> 1 file changed, 5 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile >>>> index 366771016b99..82c619791a63 100644 >>>> --- a/arch/loongarch/Makefile >>>> +++ b/arch/loongarch/Makefile >>>> @@ -51,7 +51,9 @@ LDFLAGS_vmlinux += -static -n -nostdlib >>>> >>>> # When the assembler supports explicit relocation hint, we must use it. >>>> # GCC may have -mexplicit-relocs off by default if it was built with an old >>>> -# assembler, so we force it via an option. >>>> +# assembler, so we force it via an option. For LLVM/Clang the desired behavior >>>> +# is the default, and the flag is not supported, so don't pass it if Clang is >>>> +# being used. >>>> # >>>> # When the assembler does not supports explicit relocation hint, we can't use >>>> # it. Disable it if the compiler supports it. >>>> @@ -61,8 +63,10 @@ LDFLAGS_vmlinux += -static -n -nostdlib >>>> # combination of a "new" assembler and "old" compiler is not supported. Either >>>> # upgrade the compiler or downgrade the assembler. >>>> ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS >>>> +ifndef CONFIG_CC_IS_CLANG >>>> cflags-y += -mexplicit-relocs >>>> KBUILD_CFLAGS_KERNEL += -mdirect-extern-access >>>> +endif >>> I prefer to drop CONFIG_CC_IS_CLANG and use >>> cflags-y += $(call cc-option,-mexplicit-relocs) >>> KBUILD_CFLAGS_KERNEL += $(call cc-option,-mdirect-extern-access) >>> >>> Then Patch-6 can be merged in this. >>> >>> What's your opinion? >> >> FYI: with this approach the build no longer instantly dies with binutils >> 2.40 + gcc 12.3, but there are also tons of warnings that say the model >> attribute is being ignored. I checked earlier discussions and this means >> modules are silently broken at runtime, which is not particularly good UX. > > We can add > > #if defined(MODULE) && !__has_attribute(model) > # error some fancy error message > #endif > > into percpu.h to error out in this case. It had been in my earlier > drafts of explicit relocs patches, but we dropped it because there was > no such configuration (unless a snapshot of development GCC is used, and > using such a snapshot is never supported IIUC). Ah I've seen that. So in this case we simply wrap -mexplicit-relocs with cc-option and error out in case of CONFIG_MODULE but no model attribute, which nicely prevents broken configurations (MODULE && ((old_gcc && new_binutils) || clang)) with feature detection alone. This seems elegant and better to me; Huacai, WDYT?
On Sun, Jun 25, 2023 at 3:48 PM WANG Xuerui <kernel@xen0n.name> wrote: > > On 2023/6/25 15:36, Xi Ruoyao wrote: > > On Sun, 2023-06-25 at 15:16 +0800, WANG Xuerui wrote: > >> On 2023/6/25 10:13, Huacai Chen wrote: > >>> Hi, Ruoyao, > >>> > >>> On Sun, Jun 25, 2023 at 2:42 AM WANG Xuerui <kernel@xen0n.name> wrote: > >>>> > >>>> From: WANG Xuerui <git@xen0n.name> > >>>> > >>>> Now the arch code is mostly ready for LLVM/Clang consumption, it is time > >>>> to re-organize the CFLAGS a little to actually enable the LLVM build. > >>>> > >>>> In particular, -mexplicit-relocs and -mdirect-extern-access are not > >>>> necessary nor supported on Clang; feature detection via cc-option would > >>>> not work, because that way the broken combo of "new GNU as + old GCC" > >>>> would seem to get "fixed", but actually produce broken kernels. > >>>> Explicitly depending on CONFIG_CC_IS_CLANG is thus necessary to not > >>>> regress UX for those building their own kernels. > >>>> > >>>> A build with !RELOCATABLE && !MODULE is confirmed working within a QEMU > >>>> environment; support for the two features are currently blocked on > >>>> LLVM/Clang, and will come later. > >>>> > >>>> Signed-off-by: WANG Xuerui <git@xen0n.name> > >>>> --- > >>>> arch/loongarch/Makefile | 6 +++++- > >>>> 1 file changed, 5 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile > >>>> index 366771016b99..82c619791a63 100644 > >>>> --- a/arch/loongarch/Makefile > >>>> +++ b/arch/loongarch/Makefile > >>>> @@ -51,7 +51,9 @@ LDFLAGS_vmlinux += -static -n -nostdlib > >>>> > >>>> # When the assembler supports explicit relocation hint, we must use it. > >>>> # GCC may have -mexplicit-relocs off by default if it was built with an old > >>>> -# assembler, so we force it via an option. > >>>> +# assembler, so we force it via an option. For LLVM/Clang the desired behavior > >>>> +# is the default, and the flag is not supported, so don't pass it if Clang is > >>>> +# being used. > >>>> # > >>>> # When the assembler does not supports explicit relocation hint, we can't use > >>>> # it. Disable it if the compiler supports it. > >>>> @@ -61,8 +63,10 @@ LDFLAGS_vmlinux += -static -n -nostdlib > >>>> # combination of a "new" assembler and "old" compiler is not supported. Either > >>>> # upgrade the compiler or downgrade the assembler. > >>>> ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS > >>>> +ifndef CONFIG_CC_IS_CLANG > >>>> cflags-y += -mexplicit-relocs > >>>> KBUILD_CFLAGS_KERNEL += -mdirect-extern-access > >>>> +endif > >>> I prefer to drop CONFIG_CC_IS_CLANG and use > >>> cflags-y += $(call cc-option,-mexplicit-relocs) > >>> KBUILD_CFLAGS_KERNEL += $(call cc-option,-mdirect-extern-access) > >>> > >>> Then Patch-6 can be merged in this. > >>> > >>> What's your opinion? > >> > >> FYI: with this approach the build no longer instantly dies with binutils > >> 2.40 + gcc 12.3, but there are also tons of warnings that say the model > >> attribute is being ignored. I checked earlier discussions and this means > >> modules are silently broken at runtime, which is not particularly good UX. > > > > We can add > > > > #if defined(MODULE) && !__has_attribute(model) > > # error some fancy error message > > #endif > > > > into percpu.h to error out in this case. It had been in my earlier > > drafts of explicit relocs patches, but we dropped it because there was > > no such configuration (unless a snapshot of development GCC is used, and > > using such a snapshot is never supported IIUC). > > Ah I've seen that. So in this case we simply wrap -mexplicit-relocs with > cc-option and error out in case of CONFIG_MODULE but no model attribute, > which nicely prevents broken configurations (MODULE && ((old_gcc && > new_binutils) || clang)) with feature detection alone. > > This seems elegant and better to me; Huacai, WDYT? OK, perfect. Huacai > > -- > WANG "xen0n" Xuerui > > Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/ >
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile index 366771016b99..82c619791a63 100644 --- a/arch/loongarch/Makefile +++ b/arch/loongarch/Makefile @@ -51,7 +51,9 @@ LDFLAGS_vmlinux += -static -n -nostdlib # When the assembler supports explicit relocation hint, we must use it. # GCC may have -mexplicit-relocs off by default if it was built with an old -# assembler, so we force it via an option. +# assembler, so we force it via an option. For LLVM/Clang the desired behavior +# is the default, and the flag is not supported, so don't pass it if Clang is +# being used. # # When the assembler does not supports explicit relocation hint, we can't use # it. Disable it if the compiler supports it. @@ -61,8 +63,10 @@ LDFLAGS_vmlinux += -static -n -nostdlib # combination of a "new" assembler and "old" compiler is not supported. Either # upgrade the compiler or downgrade the assembler. ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS +ifndef CONFIG_CC_IS_CLANG cflags-y += -mexplicit-relocs KBUILD_CFLAGS_KERNEL += -mdirect-extern-access +endif else cflags-y += $(call cc-option,-mno-explicit-relocs) KBUILD_AFLAGS_KERNEL += -Wa,-mla-global-with-pcrel