1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
As of Android S, this deprecation is fully complete (except for ARCH=arm on
android-4.19-stable) and step 9 which is being cleaned up for Android T.
The relevant kernel commits are:
v5.7-rc1:
commit a0d1c951ef08 ("kbuild: support LLVM=1 to switch the default tools to Clang/LLVM")
v5.15-rc1:
commit f12b034afeb3 ("scripts/Makefile.clang: default to LLVM_IAS=1")
The original version of this document is retained below:
---
In the effort to improve test coverage of the LLVM substitutes when building
Linux kernels for Android distributions, as well as minimize build
dependencies, we plan to phase kernel builds over to use the LLVM substitutes
distributed through AOSP for Android S. This will remove the kernels from being
dependent on binutils in Android. The NDK is currently the other largest
dependency.
Invoking a kernel build with all of the substitutes is tedious; see
https://www.kernel.org/doc/html/latest/kbuild/llvm.html#llvm-utilities, so
`make LLVM=1` was introduced in:
commit a0d1c951ef08 ("kbuild: support LLVM=1 to switch the default tools to Clang/LLVM")
which first landed in v5.7-rc1 and will need to be backported to at least 5.4.
Support for using Clang's "integrated assembler" is a risk; we have gotten it
working upstream, but then small changes to assembly quickly uncover missing
support. Thus `LLVM_IAS=1` is a separate flag from `LLVM=1`.
The plan for S is:
1. Ensure a0d1c951ef08 is backported to all supported kernel version branches
for S.
2. Wire up support in Android common kernel's build/build.sh to forward
`LLVM=1` to `make` from a supplied config. `LLVM=1` needs to be specified
for all invocations of `make`.
3. Update kernel configs to use `LLVM=1` and remove the individual flags like
`CC=clang`, `NM=llvm-nm`, and such.
4. Create a branch of
https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/
that only contains the GNU as (assembler) binary.
(https://android.googlesource.com/platform/prebuilts/gas/linux-x86/)
5. Update repo manifests for kernels to use the branch from 4, and ensure
kernels build cleanly.
6. Remove GNU binutils from Android kernel manifests.
5 is potentially a lot of work, depending on whether we have a lot of fixes to
backport or certain configs are broken that haven't been tested upstream.
A stretch goal, assuming we get LLVM_IAS=1 in shape:
7. Wire up support in Android common kernel's build/build.sh to forward
`LLVM_IAS=1` to `make` from a supplied config. `LLVM_IAS=1` needs to be
specified for all invocations of `make`. Alternatively, we can just modify
the top level Makefile to do what LLVM_IAS=1 would do anyways, though having
flexibility of turning it off quickly should it regress in mainline is
probably a safer bet.
8. Update kernel configs to use `LLVM_IAS=1`, unless we simply modified the top
level Makefile in 6. At this point we will be using Clang's integrated
assembler.
9. Remove prebuilts/gas/linux-x86 (from step 4) from Android kernel manifests.
I think we can get all 9 done for S, but 7,8,9 are a risk, and aren't critical
to solve for S. Luckily, our comrades over at CrOS LLVM are helping whip
Clang's integrated assembler into shape. In fact, they may end up beating us to
the punch.
See this public hotlist for some of the outstanding issues to be resolved.
https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aissue+is%3Aopen+label%3A%22%5BTOOL%5D+integrated-as%22
(Not all of those are blockers).
The version of GNU binutils distributed by AOSP is version 2.27.0.20170315 (ToT
GNU binutils is 2.35) plus cherry picks. The 5.9-rc1 linux kernel currently
requires binutils 2.23 or newer.
## Contingency Plans
Let's say a kernel change doesn't work with Clang's integrated assembler. The
immediate question is "does this change need to land now, or can we bear a
revert until Clang's integrated assembler is fixed?"
With the answer to the above question being "Yes, revert now please" then the
contingency plan is:
1. file a bug, or at least email android-llvm@googlegroups.com and
ndesaulniers@google.com.
2. revert step 9 above.
3. revert step 8 above.
4. Wait for toolchain feature or bug to be fixed in upstream LLVM.
5. Wait for AOSP LLVM release containing fix.
6. Move kernel builds to newer toolchains.
7. Reapply step 8 above.
8. Reapply step 9 above.
With the answer to the above question being "No, we can wait for assembler
support" then the contingency plan is:
1. file a bug, or at least email android-llvm@googlegroups.com and
ndesaulniers@google.com.
2. Wait for toolchain feature or bug to be fixed in upstream LLVM.
3. Wait for AOSP LLVM release containing fix.
4. Move kernel builds to newer toolchains.
|
