king
/
v811_spc009
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'main'
${ noResults }
v811_spc009/prebuilts/clang/host/linux-x86/BINUTILS_KERNEL_DEPRECATION.md

4.2 KiB
Raw Permalink Blame History

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:

  1. 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.
  2. 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.
  3. 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.