mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: WANG Xuerui <kernel@xen0n.name>
To: Xi Ruoyao <xry111@xry111.site>, Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Rui <wangrui@loongson.cn>,
	loongarch@lists.linux.dev, linux-kbuild@vger.kernel.org,
	llvm@lists.linux.dev, linux-kernel@vger.kernel.org,
	WANG Xuerui <git@xen0n.name>
Subject: Re: [PATCH v2 7/9] LoongArch: Tweak CFLAGS for Clang compatibility
Date: Sun, 25 Jun 2023 15:48:26 +0800	[thread overview]
Message-ID: <12e9a417-e655-b85b-1213-231fd68b0977@xen0n.name> (raw)
In-Reply-To: <5154e8141e2b022b477f2d2658279e94f6b02149.camel@xry111.site>

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?

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/


  reply	other threads:[~2023-06-25  7:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-24 18:40 [PATCH v2 0/9] LoongArch: Preliminary ClangBuiltLinux enablement WANG Xuerui
2023-06-24 18:40 ` [PATCH v2 1/9] LoongArch: Calculate various sizes in the linker script WANG Xuerui
2023-06-24 18:40 ` [PATCH v2 2/9] LoongArch: extable: Also recognize ABI names of registers WANG Xuerui
2023-06-24 18:40 ` [PATCH v2 3/9] LoongArch: Prepare for assemblers with proper FCSR class support WANG Xuerui
2023-06-24 18:40 ` [PATCH v2 4/9] LoongArch: Make the CPUCFG and CSR ops simple aliases of compiler built-ins WANG Xuerui
2023-06-24 18:40 ` [PATCH v2 5/9] LoongArch: Simplify the invtlb wrappers WANG Xuerui
2023-06-24 18:55   ` Xi Ruoyao
2023-06-24 19:03     ` WANG Xuerui
2023-06-25  3:17   ` bibo mao
2023-06-24 18:40 ` [PATCH v2 6/9] LoongArch: Remove all -G0 switches from CFLAGS WANG Xuerui
2023-06-24 18:40 ` [PATCH v2 7/9] LoongArch: Tweak CFLAGS for Clang compatibility WANG Xuerui
2023-06-24 19:07   ` Xi Ruoyao
2023-06-25  2:13   ` Huacai Chen
2023-06-25  7:16     ` WANG Xuerui
2023-06-25  7:36       ` Xi Ruoyao
2023-06-25  7:48         ` WANG Xuerui [this message]
2023-06-25  8:13           ` Huacai Chen
2023-06-24 18:40 ` [PATCH v2 8/9] LoongArch: Mark Clang LTO as working WANG Xuerui
2023-06-24 18:40 ` [PATCH v2 9/9] Makefile: Add loongarch target flag for Clang compilation WANG Xuerui

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=12e9a417-e655-b85b-1213-231fd68b0977@xen0n.name \
    --to=kernel@xen0n.name \
    --cc=chenhuacai@kernel.org \
    --cc=git@xen0n.name \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=loongarch@lists.linux.dev \
    --cc=wangrui@loongson.cn \
    --cc=xry111@xry111.site \
    /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

all inboxes | Powered by JetHome®