Re: [PATCH v2 3/4] Makefile: lld: tell clang to use lld

[Nick Desaulniers]

On Sat, Feb 16, 2019 at 10:09 AM Masahiro Yamada
<yamada.masahiro@xxxxxxxxxxxxx> wrote:
>
> On Thu, Feb 14, 2019 at 8:08 AM Nick Desaulniers
> <ndesaulniers@xxxxxxxxxx> wrote:
> >
> > On Wed, Feb 13, 2019 at 6:59 AM Masahiro Yamada
> > <yamada.masahiro@xxxxxxxxxxxxx> wrote:
> > >
> > > On Tue, Feb 12, 2019 at 5:42 AM <ndesaulniers@xxxxxxxxxx> wrote:
> > > >
> > > > This is needed because clang doesn't select which linker to use based on
> > > > $LD but rather -fuse-ld=lld. This is problematic especially for
> > > > cc-ldoption, which checks for linker flag support via invoking the
> > > > compiler, rather than the linker.
> > >
> > >
> > > Sorry, please explain what kind of problem
> > > this patch solves.
> > >
> > >
> > >
> > > [1] $(LD) is used to link vmlinux, modules, etc.
> > >
> > > [2] $(CC) is used to link vdso, etc.
> > >     and -fuse-ld= selects which linker is invoked from $(CC)
> >
> > It solves case 2.
> >
> > >
> > >
> > > Is it a problem to use a different
> > > type of linker for [1] and [2] ?
> >
> > Ideally, no, but I can think of at least one case where it might be
> > problematic to mix linkers like that:
> > You might be mixing linker flags added via ld-option from one linker
> > that aren't actually supported by the other linker.
>
> You can do this only when you are sure
> that the _exactly_ same linker is used.
>
> In my understanding, -fuse-ld=lld does not guarantee it.

I really don't think we should be mixing and matching linkers during a
kernel build.  When we compile with clang, we don't have escape
hatches that allow for some object files to be compiled with GCC
(mixing clang and GCC compiled object files into one build).
Following the same logic, I think mixing linkers during kernel build
should similarly be dissuaded.  This patch AVOIDS clang using a
different linker than what was specified via $LD, which is CRITICAL
for cc-ldoption kbuild macro.  Masahiro, I hope this patch can be
re-evaluated, or if I'm not understanding your point, that you can
provide additional clarification.

-- 
Thanks,
~Nick Desaulniers