From: Peter Zijlstra <peterz@infradead.org>
To: Miguel Ojeda <ojeda@kernel.org>
Cc: "Josh Poimboeuf" <jpoimboe@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Masahiro Yamada" <masahiroy@kernel.org>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nicolas Schier" <nicolas@fjasle.eu>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@samsung.com>,
"Alice Ryhl" <aliceryhl@google.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
patches@lists.linux.dev
Subject: Re: [PATCH v3 5/6] objtool/rust: list `noreturn` Rust functions
Date: Fri, 26 Jul 2024 09:04:47 +0200 [thread overview]
Message-ID: <20240726070447.GL13387@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20240725183325.122827-6-ojeda@kernel.org>
On Thu, Jul 25, 2024 at 08:33:22PM +0200, Miguel Ojeda 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@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> tools/objtool/check.c | 48 ++++++++++++++++++++++++++++++++++++++-
> tools/objtool/noreturns.h | 2 ++
> 2 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 0a33d9195b7a..deace6fca2ed 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -177,6 +177,48 @@ static bool is_sibling_call(struct instruction *insn)
> return (is_static_jump(insn) && insn_call_dest(insn));
> }
>
> +/*
> + * Checks if a string ends with another.
> + */
> +static bool str_ends_with(const char *s, const char *sub)
> +{
> + const int slen = strlen(s);
> + const int sublen = strlen(sub);
> +
> + if (sublen > slen)
> + return 0;
> +
> + return !memcmp(s + slen - sublen, sub, sublen);
> +}
> +
> +/*
> + * Checks if a function is a Rust "noreturn" one.
> + */
> +static bool is_rust_noreturn(const struct symbol *func)
> +{
> + /*
> + * If it does not start with "_R", then it is not a Rust symbol.
> + */
> + if (strncmp(func->name, "_R", 2))
> + return false;
> +
> + /*
> + * These are just heuristics -- we do not control the precise symbol
> + * name, due to the crate disambiguators (which depend on the compiler)
> + * as well as changes to the source code itself between versions (since
> + * these come from the Rust standard library).
> + */
> + return str_ends_with(func->name, "_4core6option13unwrap_failed") ||
> + str_ends_with(func->name, "_4core6result13unwrap_failed") ||
> + str_ends_with(func->name, "_4core9panicking5panic") ||
> + str_ends_with(func->name, "_4core9panicking9panic_fmt") ||
> + str_ends_with(func->name, "_4core9panicking14panic_explicit") ||
> + str_ends_with(func->name, "_4core9panicking18panic_bounds_check") ||
> + strstr(func->name, "_4core9panicking11panic_const24panic_const_") ||
> + (strstr(func->name, "_4core5slice5index24slice_") &&
> + str_ends_with(func->name, "_fail"));
> +}
> +
> /*
> * This checks to see if the given function is a "noreturn" function.
> *
> @@ -202,10 +244,14 @@ static bool __dead_end_function(struct objtool_file *file, struct symbol *func,
> if (!func)
> return false;
>
> - if (func->bind == STB_GLOBAL || func->bind == STB_WEAK)
> + if (func->bind == STB_GLOBAL || func->bind == STB_WEAK) {
> + if (is_rust_noreturn(func))
> + return true;
> +
> for (i = 0; i < ARRAY_SIZE(global_noreturns); i++)
> if (!strcmp(func->name, global_noreturns[i]))
> return true;
> + }
>
> if (func->bind == STB_WEAK)
> return false;
> diff --git a/tools/objtool/noreturns.h b/tools/objtool/noreturns.h
> index 7ebf29c91184..82a001ac433b 100644
> --- a/tools/objtool/noreturns.h
> +++ b/tools/objtool/noreturns.h
> @@ -35,6 +35,8 @@ NORETURN(panic)
> NORETURN(panic_smp_self_stop)
> NORETURN(rest_init)
> NORETURN(rewind_stack_and_make_dead)
> +NORETURN(rust_begin_unwind)
> +NORETURN(rust_helper_BUG)
> NORETURN(sev_es_terminate)
> NORETURN(snp_abort)
> NORETURN(start_kernel)
> --
> 2.45.2
>
next prev parent reply other threads:[~2024-07-26 7:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-25 18:33 [PATCH v3 0/6] Rust: support `CPU_MITIGATIONS` and enable `objtool` Miguel Ojeda
2024-07-25 18:33 ` [PATCH v3 1/6] rust: module: add static pointer to `{init,cleanup}_module()` Miguel Ojeda
2024-08-07 10:24 ` Gary Guo
2024-07-25 18:33 ` [PATCH v3 2/6] x86/rust: support MITIGATION_RETPOLINE Miguel Ojeda
2024-07-25 18:33 ` [PATCH v3 3/6] x86/rust: support MITIGATION_RETHUNK Miguel Ojeda
2024-08-09 20:03 ` Thomas Gleixner
2024-07-25 18:33 ` [PATCH v3 4/6] x86/rust: support MITIGATION_SLS Miguel Ojeda
2024-07-25 18:33 ` [PATCH v3 5/6] objtool/rust: list `noreturn` Rust functions Miguel Ojeda
2024-07-26 7:04 ` Peter Zijlstra [this message]
2024-07-26 7:41 ` Alice Ryhl
2024-08-06 19:42 ` Kees Cook
2024-08-06 20:22 ` Peter Zijlstra
2024-08-06 21:29 ` Miguel Ojeda
2024-07-25 18:33 ` [PATCH v3 6/6] objtool/kbuild/rust: enable objtool for Rust Miguel Ojeda
2024-07-25 19:10 ` [PATCH v3 0/6] Rust: support `CPU_MITIGATIONS` and enable `objtool` Benno Lossin
2024-08-18 21:34 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240726070447.GL13387@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=a.hindborg@samsung.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=gary@garyguo.net \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=nicolas@fjasle.eu \
--cc=ojeda@kernel.org \
--cc=patches@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=wedsonaf@gmail.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.