Re: [PATCH 7/9] LoongArch: Tweak CFLAGS for Clang compatibility

From: Xi Ruoyao
Date: Fri Jun 23 2023 - 12:54:05 EST


On Fri, 2023-06-23 at 09:39 -0700, Nick Desaulniers wrote:
> On Fri, Jun 23, 2023 at 6:44 AM WANG Xuerui <kernel@xxxxxxxxxx> wrote:
> >
> > From: WANG Xuerui <git@xxxxxxxxxx>
> >
> > 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@xxxxxxxxxx>
> > ---
> >  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?
>
> > -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?

-G0 is a no-op for now because there is no small bss/data optimization
implemented for LoongArch yet.

/* snip */

> Why would AS_HAS_EXPLICIT_RELOCS be set if -mexplicit-relocs isn't
> supported? Is the kconfig for that broken?

Using GCC 12 (w/o -mexplicit-relocs support) together with Binutils >=
2.39 (with explicit relocs support) will cause kernel modules fail to be
loaded (because there will be R_LARCH_ABS_* relocations in the modules
and the module loader does not support them), so we deliberately reject
such a combination at compile time.

I could add R_LARCH_ABS_* implementation into the module loader to make
it work, but Huacai suggested to just declare the combination of GCC 12
and Binutils >= 2.39 unsupported.

--
Xi Ruoyao <xry111@xxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University