On Wed, Jul 21, 2021 at 5:52 AM Nick Desaulniers
<ndesaulniers@xxxxxxxxxx> wrote:
>
> On Tue, Jul 20, 2021 at 10:43 AM Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, Jul 20, 2021 at 1:05 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
> > >
> > > LLVM=1 is a convenient switch to change all the
> > > defaults, but yet you can flip each tool individually.
> >
> > Actually, I'd argue that "LLVM=1" is *not* a convenient switch.
>
> Compared to the old way of CC=clang LD=ld.lld OBJCOPY=.... it certainly is.
>
> > Neither are the individual other command line settings.
>
> Agreed, but we needed flexibility until we could get all of the
> command line tools working for each architecture. They're still
> useful when there's a regression and we need to fall back. So I
> wouldn't be in favor of removing them (not that that's been proposed).
>
> > When clang was the odd man out, and special, it all made sense.
> > Changing the path to CC was similar to changing the path to AWK. And
> > that's obviously why we have what we have.
> >
> > But clang has become a primary compiler for some kernel communities,
> > and I think it might be time to just re-visit that entirely.
>
> :^)
>
> > In particular, I think we should just make it a Kconfig option. I hate
> > the command flag stuff so much, that my clang tree literally has this
> > patch in it:
> >
> > -CC = $(CROSS_COMPILE)gcc
> > +CC = $(CROSS_COMPILE)clang
> >
> > so that I can just do the same "make -j128" in both my gcc tree and my
> > clang tree.
>
> So you haven't been using LLD... :( (imagine using more than one
> thread to link, and being faster than ld.gold) If anything you should
> be hard coding LLVM=1 in that tree. Also, please be careful you don't
> accidentally commit that! 0:-)
>
> > But each build tree already has its own .config file, so it would be a
> > lot more convenient if that was how the compiler was chosen, and then
> > "make oldconfig" would just DTRT.
> >
> > We do most of the other heavy lifting in this area in Kconfig anyway,
> > why not add that compiler choice?
> >
> > Obviously it would be gated by the tests to see which compilers are
> > _installed_ (and that they are valid versions), so that it doesn't ask
> > stupid things ("do you want gcc or clang" when only one of them is
> > installed and/or viable).
> >
> > Hmm? So then any "LLVM=1" thing would be about the "make config"
> > stage, not the actual build stage.
> >
> > (It has annoyed me for years that if you want to cross-compile, you
> > first have to do "make ARCH=xyz config" and then remember to do "make
> > ARCH=xyz" for the build too, but I cross-compile so seldom that I've
> > never really cared).
> >
> > Let the flame wars^H^Hpolite discussions ensue..
>
> I agree with you. Overall the command line invocation of make when
> cross compiling, or when using LLVM is too long. You even call out
> LLVM=1 and ARCH separately. Each one of these had good reasons to
> exist for years.
>
> But I disagree that all needs to be sorted out together, or right now.
> And I'd much rather tackle them separately, one by one, than try to
> completely rewrite how we cross compile the kernel today.
>
> Right now, we have:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make LLVM=1 LLVM_IAS=1 -j72
>
> This series is concerned with just CROSS_COMPILE (and just for LLVM=1).
> Next I plan to default on LLVM_IAS=1 for all architectures we support,
> minus ppc and s390 where we still have some assembler bugs.
> Your/Arnd's ideas about LLVM=1 or not via Kconfig, or pre-Kconfig is a
> good idea for eliminating LLVM=1.
I also like to make the integrated assembler our default.
We can add LLVM_DISABLE_IAS=1 to
replace LLVM_IAS=1.
> Then that just leaves ARCH.
> Arnd's idea about helping you install a toolchain from kernel.org is
> one I support, but orthogonal to the above somewhat. Do you allow
> someone to have a config that denotes intent to build with clang then
> prompt if they don't have clang installed to download it? Or do you
> prevent someone from selecting building with clang because it's not in
> the $PATH?
> Your/Arnd's idea about detecting which toolchains are installed is one
> I support, but orthogonal to the above somewhat. (For that, I'm
> curious for our build servers if that means having to put tools in
> certain locations; I prefer we reference $PATH when possible. Or if
> .configs can no longer be shared if tools are in different locations.
> But perhaps that's a non-issue). I'm also curious how many stat calls
> we'll need to test/probe/find these, and how we prioritize which tools
> are selected when there's more than one version installed.
>
> I encourage us to make steps in the right direction; but I think this
> series is ready to go for at least one of the command line variables.
> I don't think we need to wait for some probing machinery to eliminate
> CROSS_COMPILE when LLVM=1; and if we ever get such machinery we can
> revisit whether that helps this case at all.
> --
> Thanks,
> ~Nick Desaulniers
--
Best Regards
Masahiro Yamada
