Challenges with Kernels built with LTO
summary
Using CONFIG_LTO_CLANG_THIN in production increases inlining surprises (about 6,800 inline-but-still-present functions without LTO vs >8,000 with LTO) and makes ftrace miss events because functions are selectively inlined. LTO also breaks binary-diff live patching: object files are LLVM IR, cross-file inlining happens in the linker, and kpatch-build cannot diff reliably; dumping IR helps but causes massive symbol renames and hash-based churn (a simple one-line patch shows 26 → hundreds of changed symbols across files). Proposed mitigations include always-inline-or-never semantics, emitting a section for partially inlined functions, and using source-file‑based names instead of IR hashes for promoted symbols.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 0:20LTO impact on tracing
- 2:24Proposed inlining solutions
- 5:34Livepatch workflows
- 7:11LTO build challenges
- 9:40Compiler behavior analysis
- 14:20Proposed symbol solutions
- 19:26Q&A and conclusion
related talks
01h 02mThinLTO: Scalable and Incremental Link-Time Optimization
30mLet's talk about Link-Time Optimization (LTO)
48mGCC Link Time Optimization and the Linux Kernel
19m"ClangBuiltLinux: What's Next?"
29mBuilding the Linux kernel with Clang- 19mClangBuiltLinux: What's Next?
34mCode Size Compiler Optimizations and Techniques for Embedded Systems
01h 04mJust-in-Time Compilation: The Next Big Thing?