From: Nick Desaulniers <ndesaulniers@google.com>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
llvm@lists.linux.dev, patches@lists.linux.dev,
Paul Mackerras <paulus@samba.org>, Tom Rix <trix@redhat.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] powerpc/vdso: Link with ld.lld when requested
Date: Mon, 9 May 2022 14:58:09 -0700 [thread overview]
Message-ID: <CAKwvOdnbTGpNvXsum-cM8i5sWuATLHouaURE1vkjuOj5rzTuqw@mail.gmail.com> (raw)
In-Reply-To: <YnmL6a8eObtstNjZ@dev-arch.thelio-3990X>
On Mon, May 9, 2022 at 2:47 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Mon, May 09, 2022 at 02:24:40PM -0700, Nick Desaulniers wrote:
> > On Mon, May 9, 2022 at 1:47 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > The PowerPC vDSO is linked with $(CC) instead of $(LD), which means the
> > > default linker of the compiler is used instead of the linker requested
> > > by the builder.
> > >
> > > $ make ARCH=powerpc LLVM=1 mrproper defconfig arch/powerpc/kernel/vdso/
> > > ...
> > >
> > > $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> > >
> > > File: arch/powerpc/kernel/vdso/vdso32.so.dbg
> > > String dump of section '.comment':
> > > [ 0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > >
> > > File: arch/powerpc/kernel/vdso/vdso64.so.dbg
> > > String dump of section '.comment':
> > > [ 0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > >
> > > The compiler option '-fuse-ld' tells the compiler which linker to use
> > > when it is invoked as both the compiler and linker. Use '-fuse-ld=lld'
> > > when LD=ld.lld has been specified (CONFIG_LD_IS_LLD) so that the vDSO is
> > > linked with the same linker as the rest of the kernel.
> > >
> > > $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> > >
> > > File: arch/powerpc/kernel/vdso/vdso32.so.dbg
> > > String dump of section '.comment':
> > > [ 0] Linker: LLD 14.0.0
> > > [ 14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > >
> > > File: arch/powerpc/kernel/vdso/vdso64.so.dbg
> > > String dump of section '.comment':
> > > [ 0] Linker: LLD 14.0.0
> > > [ 14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > >
> > > LD can be a full path to ld.lld, which will not be handled properly by
> > > '-fuse-ld=lld' if the full path to ld.lld is outside of the compiler's
> > > search path. '-fuse-ld' can take a path to the linker but it is
> > > deprecated in clang 12.0.0; '--ld-path' is preferred for this scenario.
> > >
> > > Use '--ld-path' if it is supported, as it will handle a full path or
> > > just 'ld.lld' properly. See the LLVM commit below for the full details
> > > of '--ld-path'.
> >
> > Perhaps worth adding some additional background from the cover letter
> > to the commit message that will actually go into the kernel,
> > particularly:
> > 1. Kbuild mostly invokes the compiler and linker distinctly; the ppc
> > vdso code uses the compiler as the linker driver though.
> > 2. When doing so, depending on how the compiler was configured, the
> > implicit default linker the compiler invokes might not match $LD.
>
> Sure, I think I can clear up these two points with something like:
>
> "The PowerPC vDSO uses $(CC) to link, which differs from the rest of the
> kernel, which uses $(LD) directly. As a result, the default linker of
> the compiler is used, which may differ from the linker requested by the
> builder. For example:
>
> <example above>
>
> LLVM=1 sets LD=ld.lld but ld.lld is not used to link the vDSO; GNU ld is
> because "ld" is the default linker for clang on most Linux platforms."
>
> Thoughts?
SGTM
>
> > 3. This is a problem for LTO since clang may try to invoke ld.gold,
> > which is not supported as of
> > commit 75959d44f9dc ("kbuild: Fail if gold linker is detected")
>
> Technically, it seemed like ld.bfd was being invoked but the LLVMgold
> plugin did not exist. Regardless, moving to ld.lld will resolve that,
> since the LLVMgold plugin won't be needed.
Oh indeed, invoking clang with `-flto -###` shows it does invoke the
system's linker with `-plugin path/to/LLVMgold.so`, not `ld.gold`
itself. I don't think we should use or depend on the LLVMgold.so
plugin either (I suspect it will invoke ld.gold, but as you noticed, I
don't bother to build LLVMgold.so). So, perhaps reworded (feel free
to reword further):
3. This is a problem for LTO since clang may try to invoke ld.bfd with
the LLVMgold.so plugin.
https://llvm.org/docs/GoldPlugin.html states that "usage of the LLVM
gold plugin with ld.bfd is not tested and therefore not officially
supported or recommended." Users should instead use ld.lld to drive
linking for LTO with clang.
>
> > 4. Using the linker as the driver can cause ld.bfd 2.26 to crash.
> > https://lore.kernel.org/all/b2066ccd-2b81-6032-08e3-41105b400f75@csgroup.eu/
> > (Though, I wonder if that's because I was trying to add
> > --orphan-handling=warn, which we're not yet doing for the ppc vdso
> > AFAICT).
>
> I can add this if necessary but it seemed like there might have been
> other problems reported? I could just add a blanket "linker driver had
> issues, we'll try again later" or something of that effect?
Sure.
--
Thanks,
~Nick Desaulniers
next prev parent reply other threads:[~2022-05-09 21:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 20:46 [PATCH 0/2] Link the PowerPC vDSO with ld.lld Nathan Chancellor
2022-05-09 20:46 ` [PATCH 1/2] powerpc/vdso: Remove unused ENTRY in linker scripts Nathan Chancellor
2022-05-09 21:05 ` Nick Desaulniers
2022-05-10 6:22 ` Alexey Kardashevskiy
2022-05-10 6:41 ` Fangrui Song
2022-05-09 20:46 ` [PATCH 2/2] powerpc/vdso: Link with ld.lld when requested Nathan Chancellor
2022-05-09 21:24 ` Nick Desaulniers
2022-05-09 21:47 ` Nathan Chancellor
2022-05-09 21:58 ` Nick Desaulniers [this message]
2022-05-09 22:30 ` Nathan Chancellor
2022-05-10 6:22 ` Alexey Kardashevskiy
2022-05-10 16:25 ` Nathan Chancellor
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=CAKwvOdnbTGpNvXsum-cM8i5sWuATLHouaURE1vkjuOj5rzTuqw@mail.gmail.com \
--to=ndesaulniers@google.com \
--cc=aik@ozlabs.ru \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=patches@lists.linux.dev \
--cc=paulus@samba.org \
--cc=trix@redhat.com \
/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).