2020-08-27 03:15:55 +08:00
|
|
|
.. _kbuild_llvm:
|
|
|
|
|
2020-02-27 07:23:36 +08:00
|
|
|
==============================
|
|
|
|
Building Linux with Clang/LLVM
|
|
|
|
==============================
|
|
|
|
|
|
|
|
This document covers how to build the Linux kernel with Clang and LLVM
|
|
|
|
utilities.
|
|
|
|
|
|
|
|
About
|
|
|
|
-----
|
|
|
|
|
|
|
|
The Linux kernel has always traditionally been compiled with GNU toolchains
|
|
|
|
such as GCC and binutils. Ongoing work has allowed for `Clang
|
|
|
|
<https://clang.llvm.org/>`_ and `LLVM <https://llvm.org/>`_ utilities to be
|
|
|
|
used as viable substitutes. Distributions such as `Android
|
|
|
|
<https://www.android.com/>`_, `ChromeOS
|
2023-02-03 02:05:48 +08:00
|
|
|
<https://www.chromium.org/chromium-os>`_, `OpenMandriva
|
|
|
|
<https://www.openmandriva.org/>`_, and `Chimera Linux
|
|
|
|
<https://chimera-linux.org/>`_ use Clang built kernels. Google's and Meta's
|
|
|
|
datacenter fleets also run kernels built with Clang.
|
|
|
|
|
|
|
|
`LLVM is a collection of toolchain components implemented in terms of C++
|
|
|
|
objects <https://www.aosabook.org/en/llvm.html>`_. Clang is a front-end to LLVM
|
|
|
|
that supports C and the GNU C extensions required by the kernel, and is
|
|
|
|
pronounced "klang," not "see-lang."
|
2020-02-27 07:23:36 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
Building with LLVM
|
|
|
|
------------------
|
2020-02-27 07:23:36 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
Invoke ``make`` via::
|
2020-02-27 07:23:36 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
make LLVM=1
|
2020-02-27 07:23:36 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
to compile for the host target. For cross compiling::
|
2020-02-27 07:23:36 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
make LLVM=1 ARCH=arm64
|
2020-02-27 07:23:36 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
The LLVM= argument
|
|
|
|
------------------
|
2020-02-27 07:23:36 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
LLVM has substitutes for GNU binutils utilities. They can be enabled
|
|
|
|
individually. The full list of supported make variables::
|
2020-02-27 07:23:36 +08:00
|
|
|
|
2020-08-26 07:14:38 +08:00
|
|
|
make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \
|
2020-10-23 19:57:32 +08:00
|
|
|
OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \
|
|
|
|
HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld
|
2020-02-27 07:23:36 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
``LLVM=1`` expands to the above.
|
kbuild: Make $(LLVM) more flexible
The LLVM make variable allows a developer to quickly switch between the
GNU and LLVM tools. However, it does not handle versioned binaries, such
as the ones shipped by Debian, as LLVM=1 just defines the tool variables
with the unversioned binaries.
There was some discussion during the review of the patch that introduces
LLVM=1 around versioned binaries, ultimately coming to the conclusion
that developers can just add the folder that contains the unversioned
binaries to their PATH, as Debian's versioned suffixed binaries are
really just symlinks to the unversioned binaries in /usr/lib/llvm-#/bin:
$ realpath /usr/bin/clang-14
/usr/lib/llvm-14/bin/clang
$ PATH=/usr/lib/llvm-14/bin:$PATH make ... LLVM=1
However, that can be cumbersome to developers who are constantly testing
series with different toolchains and versions. It is simple enough to
support these versioned binaries directly in the Kbuild system by
allowing the developer to specify the version suffix with LLVM=, which
is shorter than the above suggestion:
$ make ... LLVM=-14
It does not change the meaning of LLVM=1 (which will continue to use
unversioned binaries) and it does not add too much additional complexity
to the existing $(LLVM) code, while allowing developers to quickly test
their series with different versions of the whole LLVM suite of tools.
Some developers may build LLVM from source but not add the binaries to
their PATH, as they may not want to use that toolchain systemwide.
Support those developers by allowing them to supply the directory that
the LLVM tools are available in, as it is no more complex to support
than the version suffix change above.
$ make ... LLVM=/path/to/llvm/
Update and reorder the documentation to reflect these new additions.
At the same time, notate that LLVM=0 is not the same as just omitting it
altogether, which has confused people in the past.
Link: https://lore.kernel.org/r/20200317215515.226917-1-ndesaulniers@google.com/
Link: https://lore.kernel.org/r/20220224151322.072632223@infradead.org/
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-05 01:08:14 +08:00
|
|
|
|
|
|
|
If your LLVM tools are not available in your PATH, you can supply their
|
|
|
|
location using the LLVM variable with a trailing slash::
|
|
|
|
|
|
|
|
make LLVM=/path/to/llvm/
|
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
which will use ``/path/to/llvm/clang``, ``/path/to/llvm/ld.lld``, etc. The
|
|
|
|
following may also be used::
|
|
|
|
|
|
|
|
PATH=/path/to/llvm:$PATH make LLVM=1
|
kbuild: Make $(LLVM) more flexible
The LLVM make variable allows a developer to quickly switch between the
GNU and LLVM tools. However, it does not handle versioned binaries, such
as the ones shipped by Debian, as LLVM=1 just defines the tool variables
with the unversioned binaries.
There was some discussion during the review of the patch that introduces
LLVM=1 around versioned binaries, ultimately coming to the conclusion
that developers can just add the folder that contains the unversioned
binaries to their PATH, as Debian's versioned suffixed binaries are
really just symlinks to the unversioned binaries in /usr/lib/llvm-#/bin:
$ realpath /usr/bin/clang-14
/usr/lib/llvm-14/bin/clang
$ PATH=/usr/lib/llvm-14/bin:$PATH make ... LLVM=1
However, that can be cumbersome to developers who are constantly testing
series with different toolchains and versions. It is simple enough to
support these versioned binaries directly in the Kbuild system by
allowing the developer to specify the version suffix with LLVM=, which
is shorter than the above suggestion:
$ make ... LLVM=-14
It does not change the meaning of LLVM=1 (which will continue to use
unversioned binaries) and it does not add too much additional complexity
to the existing $(LLVM) code, while allowing developers to quickly test
their series with different versions of the whole LLVM suite of tools.
Some developers may build LLVM from source but not add the binaries to
their PATH, as they may not want to use that toolchain systemwide.
Support those developers by allowing them to supply the directory that
the LLVM tools are available in, as it is no more complex to support
than the version suffix change above.
$ make ... LLVM=/path/to/llvm/
Update and reorder the documentation to reflect these new additions.
At the same time, notate that LLVM=0 is not the same as just omitting it
altogether, which has confused people in the past.
Link: https://lore.kernel.org/r/20200317215515.226917-1-ndesaulniers@google.com/
Link: https://lore.kernel.org/r/20220224151322.072632223@infradead.org/
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-05 01:08:14 +08:00
|
|
|
|
|
|
|
If your LLVM tools have a version suffix and you want to test with that
|
|
|
|
explicit version rather than the unsuffixed executables like ``LLVM=1``, you
|
|
|
|
can pass the suffix using the ``LLVM`` variable::
|
|
|
|
|
|
|
|
make LLVM=-14
|
|
|
|
|
|
|
|
which will use ``clang-14``, ``ld.lld-14``, etc.
|
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
To support combinations of out of tree paths with version suffixes, we
|
|
|
|
recommend::
|
|
|
|
|
|
|
|
PATH=/path/to/llvm/:$PATH make LLVM=-14
|
|
|
|
|
kbuild: Make $(LLVM) more flexible
The LLVM make variable allows a developer to quickly switch between the
GNU and LLVM tools. However, it does not handle versioned binaries, such
as the ones shipped by Debian, as LLVM=1 just defines the tool variables
with the unversioned binaries.
There was some discussion during the review of the patch that introduces
LLVM=1 around versioned binaries, ultimately coming to the conclusion
that developers can just add the folder that contains the unversioned
binaries to their PATH, as Debian's versioned suffixed binaries are
really just symlinks to the unversioned binaries in /usr/lib/llvm-#/bin:
$ realpath /usr/bin/clang-14
/usr/lib/llvm-14/bin/clang
$ PATH=/usr/lib/llvm-14/bin:$PATH make ... LLVM=1
However, that can be cumbersome to developers who are constantly testing
series with different toolchains and versions. It is simple enough to
support these versioned binaries directly in the Kbuild system by
allowing the developer to specify the version suffix with LLVM=, which
is shorter than the above suggestion:
$ make ... LLVM=-14
It does not change the meaning of LLVM=1 (which will continue to use
unversioned binaries) and it does not add too much additional complexity
to the existing $(LLVM) code, while allowing developers to quickly test
their series with different versions of the whole LLVM suite of tools.
Some developers may build LLVM from source but not add the binaries to
their PATH, as they may not want to use that toolchain systemwide.
Support those developers by allowing them to supply the directory that
the LLVM tools are available in, as it is no more complex to support
than the version suffix change above.
$ make ... LLVM=/path/to/llvm/
Update and reorder the documentation to reflect these new additions.
At the same time, notate that LLVM=0 is not the same as just omitting it
altogether, which has confused people in the past.
Link: https://lore.kernel.org/r/20200317215515.226917-1-ndesaulniers@google.com/
Link: https://lore.kernel.org/r/20220224151322.072632223@infradead.org/
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-05 01:08:14 +08:00
|
|
|
``LLVM=0`` is not the same as omitting ``LLVM`` altogether, it will behave like
|
2023-08-26 01:38:01 +08:00
|
|
|
``LLVM=1``. If you only wish to use certain LLVM utilities, use their
|
|
|
|
respective make variables.
|
|
|
|
|
|
|
|
The same value used for ``LLVM=`` should be set for each invocation of ``make``
|
|
|
|
if configuring and building via distinct commands. ``LLVM=`` should also be set
|
|
|
|
as an environment variable when running scripts that will eventually run
|
|
|
|
``make``.
|
kbuild: Make $(LLVM) more flexible
The LLVM make variable allows a developer to quickly switch between the
GNU and LLVM tools. However, it does not handle versioned binaries, such
as the ones shipped by Debian, as LLVM=1 just defines the tool variables
with the unversioned binaries.
There was some discussion during the review of the patch that introduces
LLVM=1 around versioned binaries, ultimately coming to the conclusion
that developers can just add the folder that contains the unversioned
binaries to their PATH, as Debian's versioned suffixed binaries are
really just symlinks to the unversioned binaries in /usr/lib/llvm-#/bin:
$ realpath /usr/bin/clang-14
/usr/lib/llvm-14/bin/clang
$ PATH=/usr/lib/llvm-14/bin:$PATH make ... LLVM=1
However, that can be cumbersome to developers who are constantly testing
series with different toolchains and versions. It is simple enough to
support these versioned binaries directly in the Kbuild system by
allowing the developer to specify the version suffix with LLVM=, which
is shorter than the above suggestion:
$ make ... LLVM=-14
It does not change the meaning of LLVM=1 (which will continue to use
unversioned binaries) and it does not add too much additional complexity
to the existing $(LLVM) code, while allowing developers to quickly test
their series with different versions of the whole LLVM suite of tools.
Some developers may build LLVM from source but not add the binaries to
their PATH, as they may not want to use that toolchain systemwide.
Support those developers by allowing them to supply the directory that
the LLVM tools are available in, as it is no more complex to support
than the version suffix change above.
$ make ... LLVM=/path/to/llvm/
Update and reorder the documentation to reflect these new additions.
At the same time, notate that LLVM=0 is not the same as just omitting it
altogether, which has confused people in the past.
Link: https://lore.kernel.org/r/20200317215515.226917-1-ndesaulniers@google.com/
Link: https://lore.kernel.org/r/20220224151322.072632223@infradead.org/
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-05 01:08:14 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
Cross Compiling
|
|
|
|
---------------
|
2020-04-08 09:36:22 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
A single Clang compiler binary (and corresponding LLVM utilities) will
|
|
|
|
typically contain all supported back ends, which can help simplify cross
|
|
|
|
compiling especially when ``LLVM=1`` is used. If you use only LLVM tools,
|
|
|
|
``CROSS_COMPILE`` or target-triple-prefixes become unnecessary. Example::
|
|
|
|
|
|
|
|
make LLVM=1 ARCH=arm64
|
|
|
|
|
|
|
|
As an example of mixing LLVM and GNU utilities, for a target like ``ARCH=s390``
|
|
|
|
which does not yet have ``ld.lld`` or ``llvm-objcopy`` support, you could
|
|
|
|
invoke ``make`` via::
|
|
|
|
|
|
|
|
make LLVM=1 ARCH=s390 LD=s390x-linux-gnu-ld.bfd \
|
|
|
|
OBJCOPY=s390x-linux-gnu-objcopy
|
|
|
|
|
|
|
|
This example will invoke ``s390x-linux-gnu-ld.bfd`` as the linker and
|
|
|
|
``s390x-linux-gnu-objcopy``, so ensure those are reachable in your ``$PATH``.
|
|
|
|
|
|
|
|
``CROSS_COMPILE`` is not used to prefix the Clang compiler binary (or
|
|
|
|
corresponding LLVM utilities) as is the case for GNU utilities when ``LLVM=1``
|
|
|
|
is not set.
|
|
|
|
|
|
|
|
The LLVM_IAS= argument
|
2021-08-03 02:39:10 +08:00
|
|
|
----------------------
|
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
Clang can assemble assembler code. You can pass ``LLVM_IAS=0`` to disable this
|
|
|
|
behavior and have Clang invoke the corresponding non-integrated assembler
|
|
|
|
instead. Example::
|
|
|
|
|
|
|
|
make LLVM=1 LLVM_IAS=0
|
|
|
|
|
|
|
|
``CROSS_COMPILE`` is necessary when cross compiling and ``LLVM_IAS=0``
|
|
|
|
is used in order to set ``--prefix=`` for the compiler to find the
|
|
|
|
corresponding non-integrated assembler (typically, you don't want to use the
|
|
|
|
system assembler when targeting another architecture). Example::
|
2021-08-03 02:39:10 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
make LLVM=1 ARCH=arm LLVM_IAS=0 CROSS_COMPILE=arm-linux-gnueabi-
|
2021-08-03 02:39:10 +08:00
|
|
|
|
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
Ccache
|
|
|
|
------
|
2021-08-03 02:39:10 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
``ccache`` can be used with ``clang`` to improve subsequent builds, (though
|
|
|
|
KBUILD_BUILD_TIMESTAMP_ should be set to a deterministic value between builds
|
|
|
|
in order to avoid 100% cache misses, see Reproducible_builds_ for more info):
|
2021-08-07 01:27:01 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
KBUILD_BUILD_TIMESTAMP='' make LLVM=1 CC="ccache clang"
|
2021-08-07 01:27:01 +08:00
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
.. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp
|
|
|
|
.. _Reproducible_builds: reproducible-builds.html#timestamps
|
2021-08-03 02:39:10 +08:00
|
|
|
|
2021-01-14 08:34:47 +08:00
|
|
|
Supported Architectures
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
LLVM does not target all of the architectures that Linux supports and
|
|
|
|
just because a target is supported in LLVM does not mean that the kernel
|
|
|
|
will build or work without any issues. Below is a general summary of
|
|
|
|
architectures that currently work with ``CC=clang`` or ``LLVM=1``. Level
|
|
|
|
of support corresponds to "S" values in the MAINTAINERS files. If an
|
|
|
|
architecture is not present, it either means that LLVM does not target
|
|
|
|
it or there are known issues. Using the latest stable version of LLVM or
|
|
|
|
even the development tree will generally yield the best results.
|
|
|
|
An architecture's ``defconfig`` is generally expected to work well,
|
|
|
|
certain configurations may have problems that have not been uncovered
|
|
|
|
yet. Bug reports are always welcome at the issue tracker below!
|
|
|
|
|
|
|
|
.. list-table::
|
|
|
|
:widths: 10 10 10
|
|
|
|
:header-rows: 1
|
|
|
|
|
|
|
|
* - Architecture
|
|
|
|
- Level of support
|
|
|
|
- ``make`` command
|
|
|
|
* - arm
|
|
|
|
- Supported
|
|
|
|
- ``LLVM=1``
|
|
|
|
* - arm64
|
|
|
|
- Supported
|
|
|
|
- ``LLVM=1``
|
2022-06-18 00:58:17 +08:00
|
|
|
* - hexagon
|
|
|
|
- Maintained
|
|
|
|
- ``LLVM=1``
|
2023-08-26 01:38:01 +08:00
|
|
|
* - loongarch
|
|
|
|
- Maintained
|
|
|
|
- ``LLVM=1``
|
2021-01-14 08:34:47 +08:00
|
|
|
* - mips
|
|
|
|
- Maintained
|
2022-06-18 00:58:17 +08:00
|
|
|
- ``LLVM=1``
|
2021-01-14 08:34:47 +08:00
|
|
|
* - powerpc
|
|
|
|
- Maintained
|
2023-08-26 01:38:01 +08:00
|
|
|
- ``LLVM=1``
|
2021-01-14 08:34:47 +08:00
|
|
|
* - riscv
|
2023-08-26 01:38:01 +08:00
|
|
|
- Supported
|
2022-06-18 00:58:17 +08:00
|
|
|
- ``LLVM=1``
|
2021-01-14 08:34:47 +08:00
|
|
|
* - s390
|
|
|
|
- Maintained
|
|
|
|
- ``CC=clang``
|
2022-06-18 00:58:17 +08:00
|
|
|
* - um (User Mode)
|
|
|
|
- Maintained
|
|
|
|
- ``LLVM=1``
|
2021-01-14 08:34:47 +08:00
|
|
|
* - x86
|
|
|
|
- Supported
|
|
|
|
- ``LLVM=1``
|
|
|
|
|
2020-02-27 07:23:36 +08:00
|
|
|
Getting Help
|
|
|
|
------------
|
|
|
|
|
|
|
|
- `Website <https://clangbuiltlinux.github.io/>`_
|
2021-09-08 10:58:27 +08:00
|
|
|
- `Mailing List <https://lore.kernel.org/llvm/>`_: <llvm@lists.linux.dev>
|
|
|
|
- `Old Mailing List Archives <https://groups.google.com/g/clang-built-linux>`_
|
2020-02-27 07:23:36 +08:00
|
|
|
- `Issue Tracker <https://github.com/ClangBuiltLinux/linux/issues>`_
|
2021-09-08 10:58:30 +08:00
|
|
|
- IRC: #clangbuiltlinux on irc.libera.chat
|
2020-02-27 07:23:36 +08:00
|
|
|
- `Telegram <https://t.me/ClangBuiltLinux>`_: @ClangBuiltLinux
|
|
|
|
- `Wiki <https://github.com/ClangBuiltLinux/linux/wiki>`_
|
|
|
|
- `Beginner Bugs <https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22>`_
|
|
|
|
|
2020-08-27 03:15:55 +08:00
|
|
|
.. _getting_llvm:
|
|
|
|
|
2020-02-27 07:23:36 +08:00
|
|
|
Getting LLVM
|
|
|
|
-------------
|
|
|
|
|
2023-08-26 01:38:01 +08:00
|
|
|
We provide prebuilt stable versions of LLVM on `kernel.org
|
|
|
|
<https://kernel.org/pub/tools/llvm/>`_. These have been optimized with profile
|
|
|
|
data for building Linux kernels, which should improve kernel build times
|
|
|
|
relative to other distributions of LLVM.
|
|
|
|
|
2023-04-08 05:42:48 +08:00
|
|
|
Below are links that may be useful for building LLVM from source or procuring
|
|
|
|
it through a distribution's package manager.
|
|
|
|
|
2020-07-20 03:46:02 +08:00
|
|
|
- https://releases.llvm.org/download.html
|
2020-02-27 07:23:36 +08:00
|
|
|
- https://github.com/llvm/llvm-project
|
|
|
|
- https://llvm.org/docs/GettingStarted.html
|
|
|
|
- https://llvm.org/docs/CMake.html
|
|
|
|
- https://apt.llvm.org/
|
|
|
|
- https://www.archlinux.org/packages/extra/x86_64/llvm/
|
|
|
|
- https://github.com/ClangBuiltLinux/tc-build
|
|
|
|
- https://github.com/ClangBuiltLinux/linux/wiki/Building-Clang-from-source
|
|
|
|
- https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/
|