[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK7LNARp77d+rti7j=1ABbreTxYbVsEOHqQCurkt0t+JzKUKvg@mail.gmail.com>
Date: Sat, 26 Jul 2025 19:34:20 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas.schier@...ux.dev>,
Nick Desaulniers <nick.desaulniers+lkml@...il.com>, Bill Wendling <morbo@...gle.com>,
Justin Stitt <justinstitt@...gle.com>, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev, stable@...r.kernel.org
Subject: Re: [PATCH] kbuild: userprogs: use correct linker when mixing clang
and GNU ld
On Fri, Jul 25, 2025 at 7:36 PM Thomas Weißschuh
<thomas.weissschuh@...utronix.de> wrote:
>
> On Thu, Jul 24, 2025 at 04:10:25PM -0700, Nathan Chancellor wrote:
> > On Thu, Jul 24, 2025 at 10:32:45AM +0200, Thomas Weißschuh wrote:
> > > The userprogs infrastructure does not expect clang being used with GNU ld
> > > and in that case uses /usr/bin/ld for linking, not the configured $(LD).
> > > This fallback is problematic as it will break when cross-compiling.
> > > Mixing clang and GNU ld is used for example when building for SPARC64,
> > > as ld.lld is not sufficient; see Documentation/kbuild/llvm.rst.
> > >
> > > Relax the check around --ld-path so it gets used for all linkers.
> > >
> > > Fixes: dfc1b168a8c4 ("kbuild: userprogs: use correct lld when linking through clang")
> > > Cc: stable@...r.kernel.org
> > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> > > ---
> > > Nathan, you originally proposed the check for $(CONFIG_LD_IS_LLD) [0],
> > > could you take a look at this?
> >
> > I would expect this to be okay but I have not explicitly tested it. I
> > had not considered the case of GNU ld being used since aside from
> > sparc64, there is not another architecture that supports clang but not
> > ld.lld.
>
> FWIW some architectures use GNU ld implicitly with clang because they also link
> through $(CC) but do not use --ld-path. One example is UML, where the vDSO and
> vmlinux are linked this way. But linking vmlinux of UML with ld.lld will
> require changes to at least the linker script. Something for the ClangBuiltLinux
> TODO? There were more examples, but I don't remember them right now.
>
> Longterm --ld-path should probably be added to the global KBUILD_CFLAGS, too.
>
> > Reviewed-by: Nathan Chancellor <nathan@...nel.org>
>
> Thanks!
>
> > > ---
> > > Makefile | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index c09766beb7eff4780574682b8ea44475fc0a5188..e300c6546c845c300edb5f0033719963c7da8f9b 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1134,7 +1134,7 @@ KBUILD_USERCFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CPPFLAGS) $(KBUILD
> > > KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
> >
> > Does KBUILD_USERCFLAGS respect LLVM_IAS? sparc64 does not use the
> > integrated assembler yet (as far as I am aware) so I think we probably
> > need to filter '--prefix=' and '-fno-integrated-as' to avoid further
> > issues with assembling?
>
> No, it isn't respected. On the other hand I didn't yet run into any issues.
> Do we want to fix it proactively?
>
> > > # userspace programs are linked via the compiler, use the correct linker
> > > -ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_LD_IS_LLD),yy)
> > > +ifneq ($(CONFIG_CC_IS_CLANG),)
> >
> > At this point, I think this can just become
> >
> > ifdef CONFIG_CC_IS_CLANG
>
> Absolutetly. The existing conditional above this hunk uses the ifneq
> pattern, so I tried to keep it consistent.
> But the one above uses plain ifdef again...
> Personally I don't care one way or another.
Could you use "ifdef CONFIG_CC_IS_CLANG" please?
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists