• Miguel Ojeda's avatar
    objtool/rust: list `noreturn` Rust functions · 56d680dd
    Miguel Ojeda authored
    Rust functions may be `noreturn` (i.e. diverging) by returning the
    "never" type, `!`, e.g.
    
        fn f() -> ! {
            loop {}
        }
    
    Thus list the known `noreturn` functions to avoid such warnings.
    
    Without this, `objtool` would complain if enabled for Rust, e.g.:
    
        rust/core.o: warning: objtool:
        _R...9panic_fmt() falls through to next function _R...18panic_nounwind_fmt()
    
        rust/alloc.o: warning: objtool:
        .text: unexpected end of section
    
    In order to do so, we cannot match symbols' names exactly, for two
    reasons:
    
      - Rust mangling scheme [1] contains disambiguators [2] which we
        cannot predict (e.g. they may vary depending on the compiler version).
    
        One possibility to solve this would be to parse v0 and ignore/zero
        those before comparison.
    
      - Some of the diverging functions come from `core`, i.e. the Rust
        standard library, which may change with each compiler version
        since they are implementation details (e.g. `panic_internals`).
    
    Thus, to workaround both issues, only part of the symbols are matched,
    instead of using the `NORETURN` macro in `noreturns.h`.
    
    Ideally, just like for the C side, we should have a better solution. For
    instance, the compiler could give us the list via something like:
    
        $ rustc --emit=noreturns ...
    
    [ Kees agrees this should be automated and Peter says:
    
        So it would be fairly simple to make objtool consume a magic section
        emitted by the compiler.. I think we've asked the compiler folks
        for that at some point even, but I don't have clear recollections.
    
      We will ask upstream Rust about it. And if they agree, then perhaps
      we can get Clang/GCC to implement something similar too -- for this
      sort of thing we can take advantage of the shorter cycles of `rustc`
      as well as their unstable features concept to experiment.
    
      Gary proposed using DWARF (though it would need to be available), and
      wrote a proof of concept script using the `object` and `gimli` crates:
      https://gist.github.com/nbdd0121/449692570622c2f46a29ad9f47c3379a
    
        - Miguel ]
    
    Link: https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html [1]
    Link: https://doc.rust-lang.org/rustc/symbol-mangling/v0.html#disambiguator [2]
    Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: default avatarAlice Ryhl <aliceryhl@google.com>
    Reviewed-by: default avatarKees Cook <kees@kernel.org>
    Tested-by: default avatarBenno Lossin <benno.lossin@proton.me>
    Link: https://lore.kernel.org/r/20240725183325.122827-6-ojeda@kernel.org
    [ Added `len_mismatch_fail` symbol for new `kernel` crate code merged
      since then as well as 3 more `core::panicking` symbols that appear
      in `RUST_DEBUG_ASSERTIONS=y` builds.  - Miguel ]
    Signed-off-by: default avatarMiguel Ojeda <ojeda@kernel.org>
    56d680dd
noreturns.h 1.49 KB