[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250725122604-44874f95-859c-4c0a-b3b0-14b30e00b796@linutronix.de>
Date: Fri, 25 Jul 2025 12:36:34 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Masahiro Yamada <masahiroy@...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 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.
> > KBUILD_USERLDFLAGS += --ld-path=$(LD)
> > endif
> >
> >
> > ---
> > base-commit: 6832a9317eee280117cd695fa885b2b7a7a38daf
> > change-id: 20250723-userprogs-clang-gnu-ld-7a1c16fc852d
> >
> > Best regards,
> > --
> > Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> >
Powered by blists - more mailing lists