2023-04-18 21:27:54 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This is a (sorted!) list of all known __noreturn functions in the kernel.
|
|
|
|
|
* It's needed for objtool to properly reverse-engineer the control flow graph.
|
|
|
|
|
*
|
|
|
|
|
* Yes, this is unfortunate. A better solution is in the works.
|
|
|
|
|
*/
|
2023-04-07 19:27:13 +00:00
|
|
|
NORETURN(__fortify_panic)
|
2024-06-26 06:02:00 +00:00
|
|
|
NORETURN(__ia32_sys_exit)
|
|
|
|
|
NORETURN(__ia32_sys_exit_group)
|
2023-06-02 17:54:53 +00:00
|
|
|
NORETURN(__kunit_abort)
|
2023-04-18 21:27:54 +00:00
|
|
|
NORETURN(__module_put_and_kthread_exit)
|
|
|
|
|
NORETURN(__stack_chk_fail)
|
2023-09-18 04:18:58 +00:00
|
|
|
NORETURN(__tdx_hypercall_failed)
|
2023-04-18 21:27:54 +00:00
|
|
|
NORETURN(__ubsan_handle_builtin_unreachable)
|
2024-06-26 06:02:00 +00:00
|
|
|
NORETURN(__x64_sys_exit)
|
|
|
|
|
NORETURN(__x64_sys_exit_group)
|
2023-04-18 21:27:54 +00:00
|
|
|
NORETURN(arch_cpu_idle_dead)
|
2023-09-10 00:56:00 +00:00
|
|
|
NORETURN(bch2_trans_in_restart_error)
|
|
|
|
|
NORETURN(bch2_trans_restart_error)
|
2023-04-18 21:27:54 +00:00
|
|
|
NORETURN(cpu_bringup_and_idle)
|
|
|
|
|
NORETURN(cpu_startup_entry)
|
|
|
|
|
NORETURN(do_exit)
|
|
|
|
|
NORETURN(do_group_exit)
|
|
|
|
|
NORETURN(do_task_dead)
|
|
|
|
|
NORETURN(ex_handler_msr_mce)
|
|
|
|
|
NORETURN(hlt_play_dead)
|
|
|
|
|
NORETURN(hv_ghcb_terminate)
|
|
|
|
|
NORETURN(kthread_complete_and_exit)
|
|
|
|
|
NORETURN(kthread_exit)
|
|
|
|
|
NORETURN(kunit_try_catch_throw)
|
|
|
|
|
NORETURN(machine_real_restart)
|
|
|
|
|
NORETURN(make_task_dead)
|
|
|
|
|
NORETURN(mpt_halt_firmware)
|
|
|
|
|
NORETURN(nmi_panic_self_stop)
|
|
|
|
|
NORETURN(panic)
|
|
|
|
|
NORETURN(panic_smp_self_stop)
|
|
|
|
|
NORETURN(rest_init)
|
|
|
|
|
NORETURN(rewind_stack_and_make_dead)
|
objtool/rust: list `noreturn` Rust functions
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 ...
[ Kees agrees this should be automated and Peter says:
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.
We will ask upstream Rust about it. And if they agree, then perhaps
we can get Clang/GCC to implement something similar too -- for this
sort of thing we can take advantage of the shorter cycles of `rustc`
as well as their unstable features concept to experiment.
Gary proposed using DWARF (though it would need to be available), and
wrote a proof of concept script using the `object` and `gimli` crates:
https://gist.github.com/nbdd0121/449692570622c2f46a29ad9f47c3379a
- Miguel ]
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]
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Tested-by: Benno Lossin <benno.lossin@proton.me>
Link: https://lore.kernel.org/r/20240725183325.122827-6-ojeda@kernel.org
[ Added `len_mismatch_fail` symbol for new `kernel` crate code merged
since then as well as 3 more `core::panicking` symbols that appear
in `RUST_DEBUG_ASSERTIONS=y` builds. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-25 18:33:22 +00:00
|
|
|
NORETURN(rust_begin_unwind)
|
|
|
|
|
NORETURN(rust_helper_BUG)
|
2023-04-18 21:27:54 +00:00
|
|
|
NORETURN(sev_es_terminate)
|
|
|
|
|
NORETURN(snp_abort)
|
|
|
|
|
NORETURN(start_kernel)
|
|
|
|
|
NORETURN(stop_this_cpu)
|
|
|
|
|
NORETURN(usercopy_abort)
|
|
|
|
|
NORETURN(x86_64_start_kernel)
|
|
|
|
|
NORETURN(x86_64_start_reservations)
|
|
|
|
|
NORETURN(xen_cpu_bringup_again)
|
|
|
|
|
NORETURN(xen_start_kernel)
|