From: Miguel Ojeda <ojeda@kernel.org>
To: Josh Poimboeuf <jpoimboe@kernel.org>,
Peter Zijlstra <peterz@infradead.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>
Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nicolas Schier" <nicolas@fjasle.eu>,
"Miguel Ojeda" <ojeda@kernel.org>,
"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: [PATCH v3 5/6] objtool/rust: list `noreturn` Rust functions
Date: Thu, 25 Jul 2024 20:33:22 +0200 [thread overview]
Message-ID: <20240725183325.122827-6-ojeda@kernel.org> (raw)
In-Reply-To: <20240725183325.122827-1-ojeda@kernel.org>
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>
---
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-25 18:35 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 ` Miguel Ojeda [this message]
2024-07-26 7:04 ` [PATCH v3 5/6] objtool/rust: list `noreturn` Rust functions Peter Zijlstra
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=20240725183325.122827-6-ojeda@kernel.org \
--to=ojeda@kernel.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=patches@lists.linux.dev \
--cc=peterz@infradead.org \
--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.