Clang patch stacks for LTS kernels and status update
From: Matthias Kaehlcke
Date: Wed Nov 22 2017 - 19:11:17 EST
This is a follow-up on my earlier post on clang patch stacks for LTS
kernels (https://lkml.org/lkml/2017/8/22/912). In the meantime v4.14
(LTS) has been released, which includes almost all changes for basic
clang support, also a few issues have been fixed in clang.
Status of v4.14:
- all archs
- it is strongly recommended to use clang 5 (or higher), additional
patches are needed for clang 4 (the patches can be found in the
'_ext' patch stacks referenced below)
- allyesconfig/allmodconfig
- 4 extra patches are needed, all landed in Linus' tree for 4.15
- other architecture specific patches may be needed (see below)
- need to disable
- CONFIG_EXOFS_FS
- extensive usage of VLAIS
(http://elixir.free-electrons.com/linux/v4.14/source/fs/exofs/ore_raid.c#L74)
- CONFIG_KASAN
- clang support is WIP
- x86
- defconfig
- builds without extra patches
- allyesconfig/allmodconfig
- see 'all archs'
- allnoconfig
- (at least) errors on inline assembly constraints in percpu macros
- arm64
- all configs
- 3 extra patches are needed, two of them have landed in the
kbuild tree, the other is a workaround for a clang issue that
has been fixed, however no release with that fix is available
at this time
- defconfig
- builds with the 3 common patches
- allyesconfig/allmodconfig
- see 'all archs'
- need to disable
- CONFIG_CPU_BIG_ENDIAN
- clang 5 does not support target aarch64_be_linux
- CONFIG_ARM64_LSE_ATOMICS
- clang 5 does not support -ffixed-REG and -fcall-saved-REG
(https://bugs.llvm.org/show_bug.cgi?id=9457)
- CONFIG_VIDEO_QCOM_CAMSS
- "undefined reference to `__compiletime_assert_N
- fixed in upstream clang, no release with the fix
available yet
- still fails with "arch/arm64/kernel/entry.o:(.altinstr_replacement+0x0):
relocation truncated to fit: R_AARCH64_JUMP26 against `.entry.text"
- allnoconfig
- builds with the 3 common patches
Patch stacks for LTS kernels v4.4, v4.9 and v4.14 can be found here:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.4
https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.4_ext
https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.9
https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.9_ext
https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.14
https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.14_ext
The 4.x stacks have all necessary patches to build arm64 and x86
defconfig with clang 5, the '_ext' stacks include additional patches
for building with clang 4, fixes for warnings or issues with other
configurations like 'allyesconfig'. The OBSOLETE tag used in earlier
versions of the stack has been replaced with CLANGx tags, indicating
that a patch is only needed with clang version <= x and can be dropped
otherwise. A brief description of the other tags can be found here:
https://lkml.org/lkml/2017/8/22/912
To retrieve the patches (v4.14):
git fetch https://chromium.googlesource.com/chromiumos/third_party/kernel refs/sandbox/mka/llvm/v4.14
git checkout -b llvm_v4.14 FETCH_HEAD
To build the kernel with clang (x86/native):
make CC=clang
or cross compilation
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CC=clang
In case you wonder if kernels built with clang are actually used on
real systems, the answer is 'yes': Google Pixel 2 phones ship with
a v4.4 kernel built with clang, for several Chromebooks (both x86
and arm64) clang built kernels (also v4.4) are currently distributed
through the 'beta' channel and will be deployed to most users of these
devices in December.
For more information on this topic:
https://lwn.net/Articles/734071/
https://www.linuxplumbersconf.org/2017/ocw/system/presentations/4799/original/LPC%202017-%20Clang%20built%20kernels.pdf
https://llvm.org/devmtg/2017-10/#talk21
Thanks
Matthias