Date:   Sat, 24 Jun 2023 01:05:23 +0800
From:   WANG Xuerui <kernel@...0n.name>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Huacai Chen <chenhuacai@...nel.org>,
        WANG Rui <wangrui@...ngson.cn>, Xi Ruoyao <xry111@...111.site>,
        loongarch@...ts.linux.dev, linux-kbuild@...r.kernel.org,
        llvm@...ts.linux.dev, linux-kernel@...r.kernel.org,
        WANG Xuerui <git@...0n.name>
Subject: Re: [PATCH 7/9] LoongArch: Tweak CFLAGS for Clang compatibility


On 6/24/23 00:39, Nick Desaulniers wrote:
> On Fri, Jun 23, 2023 at 6:44 AM WANG Xuerui <kernel@...0n.name> wrote:
>> From: WANG Xuerui <git@...0n.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@...0n.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/

Powered by blists - more mailing lists