linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Maennich <maennich@google.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nathan Chancellor <natechancellor@gmail.com>,
	clang-built-linux@googlegroups.com,
	Jonathan Corbet <corbet@lwn.net>,
	Michal Marek <michal.lkml@markovi.net>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kbuild: support 'LLVM' to switch the default tools to Clang/LLVM
Date: Mon, 6 Apr 2020 13:22:20 +0200	[thread overview]
Message-ID: <20200406112220.GB126804@google.com> (raw)
In-Reply-To: <20200403051709.22407-1-masahiroy@kernel.org>

On Fri, Apr 03, 2020 at 02:17:09PM +0900, Masahiro Yamada wrote:
>As Documentation/kbuild/llvm.rst implies, building the kernel with a
>full set of LLVM tools gets very verbose and unwieldy.
>
>Provide a single switch 'LLVM' to use Clang and LLVM tools instead of
>GCC and Binutils. You can pass LLVM=1 from the command line or as an
>environment variable. Then, Kbuild will use LLVM toolchains in your
>PATH environment.
>
>Please note LLVM=1 does not turn on the LLVM integrated assembler.
>You need to explicitly pass AS=clang to use it. When the upstream
>kernel is ready for the integrated assembler, I think we can make
>it default.
>
>We discussed what we need, and we agreed to go with a simple boolean
>switch (https://lkml.org/lkml/2020/3/28/494).
>
>Some items in the discussion:
>
>- LLVM_DIR
>
>  When multiple versions of LLVM are installed, I just thought supporting
>  LLVM_DIR=/path/to/my/llvm/bin/ might be useful.
>
>  CC      = $(LLVM_DIR)clang
>  LD      = $(LLVM_DIR)ld.lld
>    ...
>
>  However, we can handle this by modifying PATH. So, we decided to not do
>  this.
>
>- LLVM_SUFFIX
>
>  Some distributions (e.g. Debian) package specific versions of LLVM with
>  naming conventions that use the version as a suffix.
>
>  CC      = clang$(LLVM_SUFFIX)
>  LD      = ld.lld(LLVM_SUFFIX)
>    ...
>
>  will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc.,
>  but the suffixed versions in /usr/bin/ are symlinks to binaries in
>  /usr/lib/llvm-#/bin/, so this can also be handled by PATH.
>
>- HOSTCC, HOSTCXX, etc.
>
>  We can switch the host compilers in the same way:
>
>  ifneq ($(LLVM),)
>  HOSTCC       = clang
>  HOSTCXX      = clang++
>  else
>  HOSTCC       = gcc
>  HOSTCXX      = g++
>  endif
>
>  This may the right thing to do, but I could not make up my mind.
>  Because we do not frequently switch the host compiler, a counter
>  solution I had in my mind was to leave it to the default of the
>  system.
>
>  HOSTCC       = cc
>  HOSTCXX      = c++

What about HOSTLD ? I saw recently, that setting HOSTLD=ld.lld is not
yielding the expected result (some tools, like e.g. fixdep still require
an `ld` to be in PATH to be built). I did not find the time to look into
that yet, but I would like to consistently switch to the llvm toolchain
(including linker and possibly more) also for hostprogs.

Cheers,
Matthias

>
>  Many distributions support update-alternatives to switch the default
>  to GCC, Clang, or whatever, but reviewers were opposed to this
>  approach. So, this commit does not touch the host tools.
>
>Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
>---
>
> Documentation/kbuild/kbuild.rst |  5 +++++
> Documentation/kbuild/llvm.rst   |  5 +++++
> Makefile                        | 20 ++++++++++++++++----
> 3 files changed, 26 insertions(+), 4 deletions(-)
>
>diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst
>index 510f38d7e78a..2d1fc03d346e 100644
>--- a/Documentation/kbuild/kbuild.rst
>+++ b/Documentation/kbuild/kbuild.rst
>@@ -262,3 +262,8 @@ KBUILD_BUILD_USER, KBUILD_BUILD_HOST
> These two variables allow to override the user@host string displayed during
> boot and in /proc/version. The default value is the output of the commands
> whoami and host, respectively.
>+
>+LLVM
>+----
>+If this variable is set to 1, Kbuild will use Clang and LLVM utilities instead
>+of GCC and GNU binutils to build the kernel.
>diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
>index d6c79eb4e23e..4602369f6a4f 100644
>--- a/Documentation/kbuild/llvm.rst
>+++ b/Documentation/kbuild/llvm.rst
>@@ -55,6 +55,11 @@ additional parameters to `make`.
> 	  READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar \\
> 	  HOSTLD=ld.lld
>
>+You can use a single switch `LLVM=1` to use LLVM utilities by default (except
>+for building host programs).
>+
>+	make LLVM=1 HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld
>+
> Getting Help
> ------------
>
>diff --git a/Makefile b/Makefile
>index c91342953d9e..6db89ecdd942 100644
>--- a/Makefile
>+++ b/Makefile
>@@ -409,16 +409,28 @@ KBUILD_HOSTLDFLAGS  := $(HOST_LFS_LDFLAGS) $(HOSTLDFLAGS)
> KBUILD_HOSTLDLIBS   := $(HOST_LFS_LIBS) $(HOSTLDLIBS)
>
> # Make variables (CC, etc...)
>-LD		= $(CROSS_COMPILE)ld
>-CC		= $(CROSS_COMPILE)gcc
> CPP		= $(CC) -E
>+ifneq ($(LLVM),)
>+CC		= clang
>+LD		= ld.lld
>+AR		= llvm-ar
>+NM		= llvm-nm
>+OBJCOPY		= llvm-objcopy
>+OBJDUMP		= llvm-objdump
>+READELF		= llvm-readelf
>+OBJSIZE		= llvm-size
>+STRIP		= llvm-strip
>+else
>+CC		= $(CROSS_COMPILE)gcc
>+LD		= $(CROSS_COMPILE)ld
> AR		= $(CROSS_COMPILE)ar
> NM		= $(CROSS_COMPILE)nm
>-STRIP		= $(CROSS_COMPILE)strip
> OBJCOPY		= $(CROSS_COMPILE)objcopy
> OBJDUMP		= $(CROSS_COMPILE)objdump
>-OBJSIZE		= $(CROSS_COMPILE)size
> READELF		= $(CROSS_COMPILE)readelf
>+OBJSIZE		= $(CROSS_COMPILE)size
>+STRIP		= $(CROSS_COMPILE)strip
>+endif
> PAHOLE		= pahole
> LEX		= flex
> YACC		= bison
>-- 
>2.17.1
>
>-- 
>You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
>To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20200403051709.22407-1-masahiroy%40kernel.org.

  parent reply	other threads:[~2020-04-06 11:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03  5:17 [PATCH] kbuild: support 'LLVM' to switch the default tools to Clang/LLVM Masahiro Yamada
2020-04-03  8:57 ` Nathan Chancellor
2020-04-03  9:26   ` Masahiro Yamada
2020-04-03 18:23 ` Nick Desaulniers
2020-04-05 16:45   ` Masahiro Yamada
2020-04-05 23:55     ` Fangrui Song
2020-04-06  1:33       ` Masahiro Yamada
2020-04-06  3:14         ` Fangrui Song
2020-04-06  9:12         ` Sedat Dilek
2020-04-06 11:22 ` Matthias Maennich [this message]
2020-04-07 16:16   ` Masahiro Yamada
2020-04-07 17:01     ` Nick Desaulniers
2020-04-07 17:46       ` Masahiro Yamada
2020-04-07 17:53         ` Nick Desaulniers
2020-04-07 19:19           ` Fangrui Song
2020-04-08  1:23             ` Masahiro Yamada

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=20200406112220.GB126804@google.com \
    --to=maennich@google.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=natechancellor@gmail.com \
    --cc=ndesaulniers@google.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).