Date Wed, 22 Nov 2017 16:11:05 -0800 From Matthias Kaehlcke <> Subject Clang patch stacks for LTS kernels and status update 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



