1//! Implementation of Rust panics via process aborts
2//!
3//! When compared to the implementation via unwinding, this crate is *much*
4//! simpler! That being said, it's not quite as versatile, but here goes!
5
6#![no_std]
7#![unstable(feature = "panic_abort", issue = "32837")]
8#![doc(issue_tracker_base_url = "https://github.com/rust-lang/rust/issues/")]
9#![panic_runtime]
10#![allow(unused_features)]
11#![feature(asm_experimental_arch)]
12#![feature(core_intrinsics)]
13#![feature(panic_runtime)]
14#![feature(std_internals)]
15#![feature(staged_api)]
16#![feature(rustc_attrs)]
17#![allow(internal_features)]
18#![deny(unsafe_op_in_unsafe_fn)]
19
20#[cfg(target_os = "android")]
21mod android;
22
23#[cfg(target_os = "zkvm")]
24mod zkvm;
25
26use core::any::Any;
27use core::panic::PanicPayload;
28
29#[rustc_std_internal_symbol]
30#[allow(improper_ctypes_definitions)]
31pub unsafe extern "C" fn __rust_panic_cleanup(_: *mut u8) -> *mut (dyn Any + Send + 'static) {
32 unreachable!()
33}
34
35// "Leak" the payload and shim to the relevant abort on the platform in question.
36#[rustc_std_internal_symbol]
37pub unsafe fn __rust_start_panic(_payload: &mut dyn PanicPayload) -> u32 {
38 // Android has the ability to attach a message as part of the abort.
39 #[cfg(target_os = "android")]
40 unsafe {
41 android::android_set_abort_message(_payload);
42 }
43 #[cfg(target_os = "zkvm")]
44 unsafe {
45 zkvm::zkvm_set_abort_message(_payload);
46 }
47
48 unsafe {
49 abort();
50 }
51
52 cfg_if::cfg_if! {
53 if #[cfg(any(unix, target_os = "solid_asp3"))] {
54 unsafe fn abort() -> ! {
55 unsafe { libc::abort(); }
56 }
57 } else if #[cfg(any(target_os = "hermit",
58 all(target_vendor = "fortanix", target_env = "sgx"),
59 target_os = "xous",
60 target_os = "uefi",
61 ))] {
62 unsafe fn abort() -> ! {
63 // call std::sys::abort_internal
64 unsafe extern "C" {
65 pub fn __rust_abort() -> !;
66 }
67 unsafe { __rust_abort(); }
68 }
69 } else if #[cfg(all(windows, not(miri)))] {
70 // On Windows, use the processor-specific __fastfail mechanism. In Windows 8
71 // and later, this will terminate the process immediately without running any
72 // in-process exception handlers. In earlier versions of Windows, this
73 // sequence of instructions will be treated as an access violation,
74 // terminating the process but without necessarily bypassing all exception
75 // handlers.
76 //
77 // https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail
78 //
79 // Note: this is the same implementation as in std's `abort_internal`
80 unsafe fn abort() -> ! {
81 #[allow(unused)]
82 const FAST_FAIL_FATAL_APP_EXIT: usize = 7;
83 cfg_if::cfg_if! {
84 if #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
85 unsafe {
86 core::arch::asm!("int $$0x29", in("ecx") FAST_FAIL_FATAL_APP_EXIT, options(noreturn, nostack));
87 }
88 } else if #[cfg(all(target_arch = "arm", target_feature = "thumb-mode"))] {
89 unsafe {
90 core::arch::asm!(".inst 0xDEFB", in("r0") FAST_FAIL_FATAL_APP_EXIT, options(noreturn, nostack));
91 }
92 } else if #[cfg(any(target_arch = "aarch64", target_arch = "arm64ec"))] {
93 unsafe {
94 core::arch::asm!("brk 0xF003", in("x0") FAST_FAIL_FATAL_APP_EXIT, options(noreturn, nostack));
95 }
96 } else {
97 core::intrinsics::abort();
98 }
99 }
100 }
101 } else if #[cfg(target_os = "teeos")] {
102 mod teeos {
103 unsafe extern "C" {
104 pub fn TEE_Panic(code: u32) -> !;
105 }
106 }
107
108 unsafe fn abort() -> ! {
109 unsafe { teeos::TEE_Panic(1); }
110 }
111 } else {
112 unsafe fn abort() -> ! {
113 core::intrinsics::abort();
114 }
115 }
116 }
117}
118
119// This... is a bit of an oddity. The tl;dr; is that this is required to link
120// correctly, the longer explanation is below.
121//
122// Right now the binaries of core/std that we ship are all compiled with
123// `-C panic=unwind`. This is done to ensure that the binaries are maximally
124// compatible with as many situations as possible. The compiler, however,
125// requires a "personality function" for all functions compiled with `-C
126// panic=unwind`. This personality function is hardcoded to the symbol
127// `rust_eh_personality` and is defined by the `eh_personality` lang item.
128//
129// So... why not just define that lang item here? Good question! The way that
130// panic runtimes are linked in is actually a little subtle in that they're
131// "sort of" in the compiler's crate store, but only actually linked if another
132// isn't actually linked. This ends up meaning that both this crate and the
133// panic_unwind crate can appear in the compiler's crate store, and if both
134// define the `eh_personality` lang item then that'll hit an error.
135//
136// To handle this the compiler only requires the `eh_personality` is defined if
137// the panic runtime being linked in is the unwinding runtime, and otherwise
138// it's not required to be defined (rightfully so). In this case, however, this
139// library just defines this symbol so there's at least some personality
140// somewhere.
141//
142// Essentially this symbol is just defined to get wired up to core/std
143// binaries, but it should never be called as we don't link in an unwinding
144// runtime at all.
145pub mod personalities {
146 // In the past this module used to contain stubs for the personality
147 // functions of various platforms, but these where removed when personality
148 // functions were moved to std.
149
150 // This corresponds to the `eh_catch_typeinfo` lang item
151 // that's only used on Emscripten currently.
152 //
153 // Since panics don't generate exceptions and foreign exceptions are
154 // currently UB with -C panic=abort (although this may be subject to
155 // change), any catch_unwind calls will never use this typeinfo.
156 #[rustc_std_internal_symbol]
157 #[allow(non_upper_case_globals)]
158 #[cfg(target_os = "emscripten")]
159 static rust_eh_catch_typeinfo: [usize; 2] = [0; 2];
160}
161