linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: WANG Xuerui <kernel@xen0n.name>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Huacai Chen <chenhuacai@kernel.org>,
	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: Re: [PATCH 7/9] LoongArch: Tweak CFLAGS for Clang compatibility
Date: Sat, 24 Jun 2023 01:05:23 +0800	[thread overview]
Message-ID: <267d223d-5215-f53d-ffb8-c74a209326e4@xen0n.name> (raw)
In-Reply-To: <CAKwvOdn5e+BzhGzDPnZYEjCuanABJmu5ZZo5x2uwHj4L44m5nA@mail.gmail.com>


On 6/24/23 00:39, Nick Desaulniers wrote:
> On Fri, Jun 23, 2023 at 6:44 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.
>>
>> A build with !RELOCATABLE && !MODULE is confirmed working within a QEMU
>> environment; support for the two features are currently blocked by
>> LLVM/Clang, and will come later.
>>
>> Signed-off-by: WANG Xuerui <git@xen0n.name>
>> ---
>>   arch/loongarch/Makefile      | 14 +++++++++++---
>>   arch/loongarch/vdso/Makefile |  6 +++++-
>>   2 files changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
>> index a27e264bdaa5..efe9b50bd829 100644
>> --- a/arch/loongarch/Makefile
>> +++ b/arch/loongarch/Makefile
>> @@ -46,12 +46,18 @@ ld-emul                     = $(64bit-emul)
>>   cflags-y               += -mabi=lp64s
>>   endif
>>
>> -cflags-y                       += -G0 -pipe -msoft-float
> This seems to drop -msoft-float for GCC. Intentional?

Kind-of; according to the LoongArch Toolchain Conventions [1], 
-msoft-float basically selects the soft-float ABI, but *also prevents 
use of any FP instructions*. This is where things get hairy, because it 
means e.g. any translation unit can't manipulate the FP context at all 
without special-casing its CFLAGS to have the -msoft-float flag removed. 
I've tried and stopped when I noticed >3 files needed such treatment 
even in arch/loongarch/kernel alone; -mabi=lp64s is always present right 
now and that's enough.

[1]: 
https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html#_compiler_options

>
>> -LDFLAGS_vmlinux                        += -G0 -static -n -nostdlib
>> +ifndef CONFIG_CC_IS_CLANG
>> +cflags-y                       += -G0
>> +LDFLAGS_vmlinux                        += -G0
> Thanks for the patch!
>
> I can understand not passing -G0 to clang if clang doesn't understand
> it, but should you be using CONFIG_LD_IS_LLD for LDFLAGS?
>
> What does -G0 do?
Just as Ruoyao explained earlier, it's the "small data threshold". It's 
not implemented on LoongArch yet, and we don't have ABI provisions for 
that either, so IMO it's even okay to just drop it unconditionally. (I 
haven't double-checked the GCC behavior though.)
>
> Is there a plan to support it in clang and lld?
>
> If so, please file a bug in LLVM's issue tracker
> https://github.com/llvm/llvm-project/issues
> then link to it in a comment in this Makefile above the relevant condition.
As explained above, proper support for "small data optimization" 
probably means some cooperation from ABI side (e.g. reserving a GP 
register for being able to reference +/-4KiB from it with a single 
insn), so I don't expect this to happen anytime soon.
>
>> +endif
>> +cflags-y                       += -pipe
>> +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 +67,10 @@ LDFLAGS_vmlinux                      += -G0 -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
> Why would AS_HAS_EXPLICIT_RELOCS be set if -mexplicit-relocs isn't
> supported? Is the kconfig for that broken?
>
> Does AS_HAS_EXPLICIT_RELOCS also need to test for the support for
> -mdirect-extern-access or should there be a new config for that?
> CC_SUPPORTS_DIRECT_EXTERN_ACCESS
>
>>   else
>>   cflags-y                       += $(call cc-option,-mno-explicit-relocs)
>>   KBUILD_AFLAGS_KERNEL           += -Wa,-mla-global-with-pcrel
>> diff --git a/arch/loongarch/vdso/Makefile b/arch/loongarch/vdso/Makefile
>> index 4c859a0e4754..19f6c75a1106 100644
>> --- a/arch/loongarch/vdso/Makefile
>> +++ b/arch/loongarch/vdso/Makefile
>> @@ -25,13 +25,17 @@ endif
>>   cflags-vdso := $(ccflags-vdso) \
>>          -isystem $(shell $(CC) -print-file-name=include) \
>>          $(filter -W%,$(filter-out -Wa$(comma)%,$(KBUILD_CFLAGS))) \
>> -       -O2 -g -fno-strict-aliasing -fno-common -fno-builtin -G0 \
>> +       -O2 -g -fno-strict-aliasing -fno-common -fno-builtin \
>>          -fno-stack-protector -fno-jump-tables -DDISABLE_BRANCH_PROFILING \
>>          $(call cc-option, -fno-asynchronous-unwind-tables) \
>>          $(call cc-option, -fno-stack-protector)
>>   aflags-vdso := $(ccflags-vdso) \
>>          -D__ASSEMBLY__ -Wa,-gdwarf-2
>>
>> +ifndef CONFIG_CC_IS_CLANG
>> +cflags-vdso += -G0
>> +endif
>> +
>>   ifneq ($(c-gettimeofday-y),)
>>     CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
>>   endif
>> --
>> 2.40.0
>>
>>
>
-- 
WANG "xen0n" Xuerui

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


  parent reply	other threads:[~2023-06-23 17:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-23 13:43 [PATCH 0/9] LoongArch: Preliminary ClangBuiltLinux enablement WANG Xuerui
2023-06-23 13:43 ` [PATCH 1/9] LoongArch: Calculate various sizes in the linker script WANG Xuerui
2023-06-23 13:43 ` [PATCH 2/9] LoongArch: extable: Also recognize ABI names of registers WANG Xuerui
2023-06-23 13:43 ` [PATCH 3/9] LoongArch: Prepare for assemblers with proper FCSR bank support WANG Xuerui
2023-06-23 16:00   ` Huacai Chen
2023-06-23 13:43 ` [PATCH 4/9] LoongArch: Make {read,write}_fcsr compatible with LLVM/Clang WANG Xuerui
2023-06-23 16:03   ` Huacai Chen
2023-06-23 13:43 ` [PATCH 5/9] LoongArch: Make the CPUCFG and CSR ops simple aliases of compiler built-ins WANG Xuerui
2023-06-23 13:43 ` [PATCH 6/9] LoongArch: Simplify the invtlb wrappers WANG Xuerui
2023-06-23 15:57   ` Huacai Chen
2023-06-23 13:43 ` [PATCH 7/9] LoongArch: Tweak CFLAGS for Clang compatibility WANG Xuerui
2023-06-23 16:39   ` Nick Desaulniers
2023-06-23 16:53     ` Xi Ruoyao
2023-06-23 17:05     ` WANG Xuerui [this message]
2023-06-23 17:00   ` Xi Ruoyao
2023-06-23 17:06     ` WANG Xuerui
2023-06-23 13:43 ` [PATCH 8/9] Makefile: Add loongarch target flag for Clang compilation WANG Xuerui
2023-06-23 15:58   ` Huacai Chen
2023-06-23 16:31   ` Nick Desaulniers
2023-06-23 13:43 ` [PATCH 9/9] LoongArch: Mark Clang LTO as working WANG Xuerui
2023-06-23 16:52   ` Nick Desaulniers

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=267d223d-5215-f53d-ffb8-c74a209326e4@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=ndesaulniers@google.com \
    --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;
as well as URLs for NNTP newsgroup(s).