Another month, another post about the work that I have done as a kernel/compiler developer! One of the highlights this month is that I got LLVM commit access so I can merge my own patches into LLVM, which I did twice so far.

Linux kernel patches

  • powerpc/fadump: Mark fadump_calculate_reserve_size as __init: LLVM 13 switched over to the New Pass Manager (NPM), which has impacted some inlining decisions, which in turn exposed some bugs in section annotations. The kernel places certain functions and variables into specific sections that are discarded and freed after init. If a non-init function calls an init function, that is technically a use-after-free so the kernel warns when this happens. In this particular case, identical_pvr_fixup() was not marked as __init and it was not getting inlined so the calls to identify_cpu() and of_get_flat_dt_prop() resulting in the modpost warnings. In practice, this is not an issue because identical_pvr_fixup() is only called from __init context but it is important to get these things right so that real warnings can easily be caught.

  • powerpc/prom: Mark identical_pvr_fixup as __init: Same situation as above :)

  • Makefile: Remove '--gcc-toolchain' flag and Makefile: Only specify '--prefix=' when building with clang + GNU as: These two patches clean up our clang specific compiler flags. I noticed that we specify --prefix= with a full path after commit ca9b31f6bb9c (“Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation”), meaning that --gcc-toolchain= is unnecessary because the kernel uses nothing within the sysroot usually provided by GCC. As a follow up, specifying --prefix= is only necessary when we are using the GNU assembler.

  • ARM: Make UNWINDER_ARM depend on ld.bfd or ld.lld 11.0.0+: A workaround for a bug in all LLD versions prior to 11.0.0. The kernel’s minimum supported version of LLVM is 10.0.1, meaning that if something is broken with LLVM 10.0.1+, it must be fixed or worked around. KernelCI has run into this as their testing plan is now the minimum supported version of LLVM and the latest stable version.

  • riscv: Fix CONFIG_FUNCTION_TRACER with clang: This series fixes build errors on RISC-V when CONFIG_FUNCTION_TRACER is set. This was a rather fun series to develop but at the same time, incredibly frustrating because of how it evolved. Unfortunately, it requires a kind of ugly workaround due to an LLVM bug (more on that below). I am hoping that it will be picked up before Linux 5.12 is released but it is not like it cannot be backported to stable.

  • riscv: Use $(LD) instead of $(CC) to link vDSO: In traditional projects, the linker is never directly invoked; instead, the compiler is called and it calls the linker implicitly. For the kernel, it is the other way around: the compiler is only used to build .o files and the linker is directly invoked on them, except in certain vDSO Makefiles. We have been working on getting rid of this and making the behavior consistent over the kernel so that ld.lld can be used in more places, as clang by default defauls to calling ld.bfd.

  • Fix cross compiling x86 with clang: Back in December, someone reported that x86 was not cross compilable due to a lack of the --target= flag. This is not a very common task as x86 is the dominant architecture but arm64 is starting to become more common, especially with Apple’s M1 chip. This series adds the --target= flag to specific subdirectories that have hand rolled KBUILD_CFLAGS (which is an antipattern that should really be avoided but simple fix for now).

LLVM patches

I contributed a few small patches to LLVM this month:

Patch review and input

I feel like I gave more input/review this month than I have before, which is never a bad thing :) Being a quick reviewer for others incentivizes them to give you a quick review in return. For some of the links below, I linked the top message/patch; my full input can be seen at the bottom by clicking on my name.

Issue triage and reporting

Healthy dose of LLVM regressions and Linux kernel build failures due to new functionality.

Tooling patches

I focused on streamlining our boot utilities, increasing the build coverage, and improving the toolchain build scripts.

Conclusion

When dealing with various issues all at once, it is hard to see any progress being made so doing these status reports is a great way to help keep myself grounded and realize that progress is indeed being made. There are some cool things in development such as Sami Tolvanen’s Control Flow Integrity series, which is high priority for testing on arm64. Stay tuned for more on that!