[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH5fLgi9xN2igQK4Y8ZCU+iPVMH2RaWGQ7OO2OV-XROJba_2fw@mail.gmail.com>
Date: Fri, 26 Jul 2024 09:41:05 +0200
From: Alice Ryhl <aliceryhl@...gle.com>
To: Miguel Ojeda <ojeda@...nel.org>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, Masahiro Yamada <masahiroy@...nel.org>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>,
Wedson Almeida Filho <wedsonaf@...il.com>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...sung.com>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
patches@...ts.linux.dev
Subject: Re: [PATCH v3 5/6] objtool/rust: list `noreturn` Rust functions
On Thu, Jul 25, 2024 at 8:35 PM Miguel Ojeda <ojeda@...nel.org> wrote:
>
> 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 ...
>
> 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]
> Signed-off-by: Miguel Ojeda <ojeda@...nel.org>
Tested-by: Alice Ryhl <aliceryhl@...gle.com>
Powered by blists - more mailing lists