Re: [PATCH 1/2] kbuild: rust: preserve unreachable traps with inline helpers

["Gary Guo" <gary@garyguo.net>]

On Tue Aug 18, 2026 at 4:18 AM BST, Josh Poimboeuf wrote:
> On Sun, Aug 16, 2026 at 03:32:32PM +0200, Miguel Ojeda wrote:
>> When `CONFIG_RUST_INLINE_HELPERS` is enabled, it is possible to hit
>> `objtool` warnings like:
>> 
>>     vmlinux.o: warning: objtool: _R..._4cmdq12CommandToGsp4init()
>>     falls through to next function _R..._4core5array4iter8IntoIterRShKj3_EEEBa_()
>> 
>> `rustc` normally emits traps for unreachable paths. However, under
>> `CONFIG_RUST_INLINE_HELPERS=y`, `rustc` emits LLVM bitcode and Clang
>> performs final code generation after the helper bitcode is linked,
>> but Clang does not trap unreachable IR by default.
>> 
>> In turn, this means `objtool` follows compiler-generated impossible Rust
>> `enum` paths through alignment padding into the next function, resulting
>> in fallthrough warnings.
>> 
>> Thus pass the LLVM `trap-unreachable` option to the final Clang invocation
>> and suppress traps immediately after `noreturn` calls, which `objtool`
>> already recognizes as dead ends. The combination of both flags makes it
>> match `rustc`'s behavior.
>> 
>> Rust 1.85.0 (the minimum supported one) supports LLVM >= 18, and both
>> flags are available in LLVM 18.
>
> FWIW, I've been working on some patches that should hopefully let us get
> rid of all the objtool hard-coded noreturn lists altogether.  I'll try to post
> those soon.

That'll be nice. I once prototyped a generator for such list by using dwarf
debug info, but obviously that cannot be part of objtool because objtool
operates independently from dwarf.

Looking forward to your approach and how you solve this. Please keep me (and the
rust-for-linux list) in cc when you do.

Thanks,
Gary