rustc: Implement custom panic runtimes #32900

alexcrichton · 2016-04-12T02:34:46Z

This commit is an implementation of RFC 1513 which allows applications to
alter the behavior of panics at compile time. A new compiler flag, -C panic,
is added and accepts the values unwind or panic, with the default being
unwind. This model affects how code is generated for the local crate, skipping
generation of landing pads with -C panic=abort.

Panic implementations are then provided by crates tagged with
#![panic_runtime] and lazily required by crates with
#![needs_panic_runtime]. The panic strategy (-C panic value) of the panic
runtime must match the final product, and if the panic strategy is not abort
then the entire DAG must have the same panic strategy.

With the -C panic=abort strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the -C panic=unwind strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the sys_common::unwind module in
favor of some bits moving part of it to libpanic_unwind and the rest into the
panicking module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the -C panic flag into account).

Closes #32837

alexcrichton · 2016-04-12T02:35:41Z

r? @nikomatsakis

retep998 · 2016-04-12T02:51:51Z

src/libpanic_abort/lib.rs

+        extern "system" {
+            fn ExitProcess(code: u32) -> !;
+        }
+        ExitProcess(101);


This is a rather quiet way of exiting the process. If we want something that debuggers will notice we need a noisier way of killing the process, like say __fastfail.

I'd be fine doing so, but it doesn't appear that there's a function we can call anywhere? Must we resort to assembly to actually do that?

Unfortunately it is an intrisic so unless LLVM gets an intrinsic for it, there's not much we can do other than using assembly. Alternatively we can raise an uncatchable exception as described here.

Or wait, never mind, there is the function RaiseFailFastException although it requires Windows 7 at a minimum.

Ok, I've updated to just use intrinsics::abort for now and we can perhaps look into fastfail later

brson · 2016-04-12T03:14:23Z

Sweet patch.

Ericson2314 · 2016-04-12T03:41:42Z

src/bootstrap/rustc.rs

+    //
+    // This... is a bit of a hack how we detect this. Ideally this information
+    // should be encoded in the crate I guess? Would likely require an RFC
+    // amendment to RFC 1513, however.


Hmm, isn't this what [profile.dev] panic = 'unwind' is for?

No, that's meant for compiling an entire DAG with a particular panic runtime

Ah gotcha, because even when building panic_abort alone, there's the deps of libc, alloc, and core in the DAG too. Sorry for the noise.

arielb1 · 2016-04-12T11:29:36Z

src/libstd/panicking.rs

+    });
+
+    fn get_call<F: FnMut()>(_: &mut F) -> fn(&mut F) {
+        call


<F as FnMut>::call_mut

Hm good point! This felt a little weird... The signature of that though is:

extern "rust-call" fn(&mut F, ());

Which I'm slightly hesitant to transmute to fn(*mut u8) due to the second argument...

bors · 2016-04-12T14:19:05Z

☔ The latest upstream changes (presumably #32804) made this pull request unmergeable. Please resolve the merge conflicts.

nikomatsakis · 2016-04-12T18:53:38Z

src/libpanic_unwind/gcc/mod.rs

+//! The first one is the personality routine described above.  The second one
+//! allows compilation target to customize the process of resuming unwind at the
+//! end of the landing pads. `eh_unwind_resume` is used only if
+//! `custom_unwind_resume` flag in the target options is set.


huzzah for comments :)

nikomatsakis · 2016-04-12T19:09:14Z

r=me once tidy errors are fixed. this is nice.

alexcrichton · 2016-04-12T20:01:00Z

@bors: r=nikomatsakis a9e4f62

alexcrichton · 2016-04-12T23:01:30Z

@bors: r=nikomatsakis 30fbd36

bors · 2016-04-14T15:19:28Z

⌛ Testing commit 30fbd36 with merge 5702651...

bors · 2016-04-14T15:23:10Z

💔 Test failed - auto-win-msvc-64-cargotest

alexcrichton · 2016-04-14T16:03:01Z

@bors: r+ 2ef34ad

alexcrichton · 2016-04-14T16:03:15Z

er,

@bors: r=nikomatsakis 2ef34ad

bors · 2016-04-14T16:03:15Z

💡 This pull request was already approved, no need to approve it again.

There's another pull request that is currently being tested, blocking this pull request: prevent other encode methods from breaking derive(RustcEncodable) #32908

alexcrichton · 2016-04-14T18:25:14Z

@bors: r=nikomatsakis 155a9c6

bors · 2016-05-09T03:10:25Z

☔ The latest upstream changes (presumably #33360) made this pull request unmergeable. Please resolve the merge conflicts.

alexcrichton · 2016-05-09T04:55:02Z

@bors: r=nikomatsakis 451c9b4

bors · 2016-05-09T05:20:18Z

⌛ Testing commit 451c9b4 with merge 39baa87...

bors · 2016-05-09T08:00:04Z

💔 Test failed - auto-win-gnu-64-opt

This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account).

samlh · 2016-05-09T22:44:42Z

src/libpanic_abort/lib.rs

 #[cfg(not(stage0))]
-pub extern fn rust_eh_personality() {}
+pub mod peronalities {


s/peronalities/personalities/

Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * rust-lang#33112 - faults like segfaults and illegal instructions will run destructors in Rust, meaning we keep running code after a super-fatal exception has happened. * rust-lang#33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions, meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of "personality function" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler`, but they both essentially are the "most generic" personality functions for catching exceptions and running cleanups. That is, thse two personalities will run cleanups for all exceptions unconditionally, so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to "C++ exception-like unwining"). Also note that the standard library only *catches* Rust exceptions, not others like segfaults and illegal instructions. LLVM has support for another personality, `__CxxFrameHandler3`, which does not run cleanups for general exceptions, only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case, so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet, but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself, but this... Closes rust-lang#33112 Closes rust-lang#33116

alexcrichton · 2016-05-10T00:29:12Z

@bors: r=nikomatsakis 38e6e5d

bors · 2016-05-10T01:23:49Z

⌛ Testing commit 38e6e5d with merge 72ed7e7...

rustc: Implement custom panic runtimes This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account). Closes #32837

bors · 2016-05-10T04:31:53Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-32cross-opt, auto-linux-64-cargotest, auto-linux-64-cross-armhf, auto-linux-64-cross-armsf, auto-linux-64-cross-freebsd, auto-linux-64-cross-netbsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-cross-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild

alexcrichton · 2016-05-10T04:46:26Z

19th time's the charm

alexcrichton mentioned this pull request Apr 12, 2016

Pluggable panic implementations (tracking issue for RFC 1513) #32837

Open

alexcrichton assigned nikomatsakis Apr 12, 2016

retep998 reviewed Apr 12, 2016
View reviewed changes

Ericson2314 reviewed Apr 12, 2016
View reviewed changes

alexcrichton force-pushed the panic2abort branch from d7f2e11 to 936aee5 Compare April 12, 2016 05:28

arielb1 reviewed Apr 12, 2016
View reviewed changes

alexcrichton force-pushed the panic2abort branch 2 times, most recently from d7e2d4d to 22b5ae0 Compare April 12, 2016 16:25

nikomatsakis reviewed Apr 12, 2016
View reviewed changes

alexcrichton force-pushed the panic2abort branch from 22b5ae0 to a9e4f62 Compare April 12, 2016 20:00

alexcrichton added the relnotes Marks issues that should be documented in the release notes of the next release. label Apr 12, 2016

alexcrichton force-pushed the panic2abort branch from a9e4f62 to 30fbd36 Compare April 12, 2016 23:01

alexcrichton force-pushed the panic2abort branch from 30fbd36 to 2ef34ad Compare April 14, 2016 16:02

alexcrichton force-pushed the panic2abort branch from 2ef34ad to 155a9c6 Compare April 14, 2016 18:25

alexcrichton force-pushed the panic2abort branch from 155a9c6 to cc62450 Compare April 14, 2016 18:30

alexcrichton force-pushed the panic2abort branch from 4105144 to 451c9b4 Compare May 9, 2016 04:53

alexcrichton force-pushed the panic2abort branch 2 times, most recently from 16ea0fa to 3ac27d9 Compare May 9, 2016 16:52

samlh reviewed May 9, 2016
View reviewed changes

alexcrichton force-pushed the panic2abort branch from 3ac27d9 to 4ade7c1 Compare May 10, 2016 00:28

alexcrichton force-pushed the panic2abort branch from 4ade7c1 to 38e6e5d Compare May 10, 2016 00:28

bors merged commit 38e6e5d into rust-lang:master May 10, 2016

This was referenced May 10, 2016

std: Funnel all aborts through rtabort! cc #31519 #32832

Closed

std: Partial fix for #33368 #33408

Closed

alexcrichton deleted the panic2abort branch May 10, 2016 04:46

mcarton mentioned this pull request May 12, 2016

Rustup to *1.10.0-nightly (22ac88f1a 2016-05-11)* rust-lang/rust-clippy#922

Merged

alexcrichton mentioned this pull request May 21, 2016

Use libc::abort, not intrinsics::abort, in rtabort! #31457

Merged

SSheldon mentioned this pull request Jun 25, 2016

Linker error for cdylib with panic=abort (Undefined symbol "_rust_eh_personality_catch") #34472

Open

MageSlayer mentioned this pull request Feb 2, 2018

LTO + >=O2 cripples panics #47965

Closed

snf mentioned this pull request Mar 3, 2018

Tracking issue for try_reserve: RFC 2116 fallible collection allocation #48043

Open

5 tasks

BatmanAoD mentioned this pull request Jun 14, 2019

Well-defined unwinding through FFI boundaries rust-lang/rfcs#2699

Closed

This was referenced Dec 7, 2022

Improved Test Coverage. bytecodealliance/wasmtime-dotnet#192

Merged

Wasmtime C API: Possibility of switching to "abort" panic mode? bytecodealliance/wasmtime#5399

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rustc: Implement custom panic runtimes #32900

rustc: Implement custom panic runtimes #32900

alexcrichton commented Apr 12, 2016

alexcrichton commented Apr 12, 2016

retep998 Apr 12, 2016

alexcrichton Apr 12, 2016

retep998 Apr 12, 2016

retep998 Apr 12, 2016

alexcrichton Apr 12, 2016

brson commented Apr 12, 2016

Ericson2314 Apr 12, 2016

alexcrichton Apr 12, 2016

Ericson2314 Apr 12, 2016

arielb1 Apr 12, 2016

alexcrichton Apr 12, 2016

bors commented Apr 12, 2016

nikomatsakis Apr 12, 2016

nikomatsakis commented Apr 12, 2016

alexcrichton commented Apr 12, 2016

alexcrichton commented Apr 12, 2016

bors commented Apr 14, 2016

bors commented Apr 14, 2016

alexcrichton commented Apr 14, 2016

alexcrichton commented Apr 14, 2016

bors commented Apr 14, 2016

alexcrichton commented Apr 14, 2016

bors commented May 9, 2016

alexcrichton commented May 9, 2016

bors commented May 9, 2016

bors commented May 9, 2016

samlh May 9, 2016

alexcrichton commented May 10, 2016

bors commented May 10, 2016

bors commented May 10, 2016

alexcrichton commented May 10, 2016

rustc: Implement custom panic runtimes #32900

rustc: Implement custom panic runtimes #32900

Conversation

alexcrichton commented Apr 12, 2016

alexcrichton commented Apr 12, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brson commented Apr 12, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Apr 12, 2016

Choose a reason for hiding this comment

nikomatsakis commented Apr 12, 2016

alexcrichton commented Apr 12, 2016

alexcrichton commented Apr 12, 2016

bors commented Apr 14, 2016

bors commented Apr 14, 2016

alexcrichton commented Apr 14, 2016

alexcrichton commented Apr 14, 2016

bors commented Apr 14, 2016

alexcrichton commented Apr 14, 2016

bors commented May 9, 2016

alexcrichton commented May 9, 2016

bors commented May 9, 2016

bors commented May 9, 2016

Choose a reason for hiding this comment

alexcrichton commented May 10, 2016

bors commented May 10, 2016

bors commented May 10, 2016

alexcrichton commented May 10, 2016