Re: [PATCH v3 5/6] objtool/rust: list `noreturn` Rust functions
From: Peter Zijlstra
Date: Tue Aug 06 2024 - 16:22:53 EST
On Tue, Aug 06, 2024 at 12:42:41PM -0700, Kees Cook wrote:
> 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 ...
>
> Yeah, having added noreturns to objtool myself a few times, it'd be nice
> to have a way to make these manual lists go away some day.
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.