From: Gary Guo <gary@garyguo.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"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>,
"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 v2 5/6] objtool: list `noreturn` Rust functions
Date: Wed, 21 Aug 2024 16:28:46 +0100 [thread overview]
Message-ID: <20240821162846.5f9ead69@eugeo> (raw)
In-Reply-To: <20240725083355.GD13387@noisy.programming.kicks-ass.net>
On Thu, 25 Jul 2024 10:33:55 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Jul 24, 2024 at 08:35:49PM +0100, Gary Guo wrote:
> > > @@ -202,10 +216,30 @@ 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) {
> > > + /*
> > > + * Rust standard library functions.
> > > + *
> > > + * 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.
> > > + */
> > > + if (!strncmp(func->name, "_R", 2) &&
> > > + (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"))))
> > > + return true;
> > > +
>
> Perhaps add a helper function: is_rust_noreturn() or somesuch.
>
> > I wonder if we should use dwarf for this. There's DW_AT_noreturn which
> > tells us exactly what we want. This would also remove the need for the
> > hardcoded C symbol list. I do recognise that debug info is not required
> > for objtool though...
>
> I think the slightly longer term plan here was to have noreturn.h
> generated from a DWARF build but still included verbatim in the objtool
> source, such that it works even on regular builds.
>
> (and can be augmented where the compilers are being 'funny')
>
> It's just that nobody has had time to implement this... you fancy giving
> this a stab?
The information extraction from dwarf is quite easy: I produced a tiny
cargo script that would be able to extract the info from an object file
(Miguel mentioned it in one of the replies):
https://gist.github.com/nbdd0121/449692570622c2f46a29ad9f47c3379a
I think the issue is that the list of noreturn symbols changes
depending on the configuration, so it's kind of difficult to
pregenerate this information.
Do you think it makes sense to have Rust object files always have DWARF
enabled, and we check Rust noreturn symbols using DWARF, while keep the
hardcoded C symbol list?
Best,
Gary
next prev parent reply other threads:[~2024-08-21 15:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 16:14 [PATCH v2 0/6] Rust: support `CPU_MITIGATIONS` and enable `objtool` Miguel Ojeda
2024-07-24 16:14 ` [PATCH v2 1/6] rust: module: add static pointer to `{init,cleanup}_module()` Miguel Ojeda
2024-07-24 19:46 ` Gary Guo
2024-07-25 17:44 ` Miguel Ojeda
2024-07-25 17:46 ` Miguel Ojeda
2024-07-25 17:47 ` Miguel Ojeda
2024-07-30 11:18 ` Gary Guo
2024-07-24 16:14 ` [PATCH v2 2/6] x86/rust: support MITIGATION_RETPOLINE Miguel Ojeda
2024-07-24 19:38 ` Gary Guo
2024-07-24 16:14 ` [PATCH v2 3/6] x86/rust: support MITIGATION_RETHUNK Miguel Ojeda
2024-07-24 19:40 ` Gary Guo
2024-07-24 16:14 ` [PATCH v2 4/6] x86/rust: support MITIGATION_SLS Miguel Ojeda
2024-07-24 19:42 ` Gary Guo
2024-07-24 16:14 ` [PATCH v2 5/6] objtool: list `noreturn` Rust functions Miguel Ojeda
2024-07-24 19:35 ` Gary Guo
2024-07-25 8:33 ` Peter Zijlstra
2024-08-21 15:28 ` Gary Guo [this message]
2024-07-24 16:14 ` [PATCH v2 6/6] objtool/kbuild/rust: enable objtool for Rust Miguel Ojeda
2024-07-24 21:51 ` [PATCH v2 0/6] Rust: support `CPU_MITIGATIONS` and enable `objtool` Benno Lossin
2024-07-25 8:38 ` Peter Zijlstra
2024-07-25 9:53 ` Miguel Ojeda
2024-07-25 9:43 ` Alice Ryhl
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=20240821162846.5f9ead69@eugeo \
--to=gary@garyguo.net \
--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=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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).