|
1 | 1 | # Panic runtimes
|
| 2 | +[top]: #panic-runtimes |
2 | 3 |
|
3 |
| -XXX fill me in... |
| 4 | +By default, the `panic!` macro unwinds Rust frames, just as C++'s `throw` |
| 5 | +unwinds C++ frames. The actual behavior of `panic!` is controlled by the _panic |
| 6 | +runtime_. The Rust standard library provides two panic runtimes: `panic_unwind` |
| 7 | +(the default) and `panic_abort`, which immediately aborts the process. |
| 8 | +When compiling code that is guaranteed (via a [compiler |
| 9 | +option][rustc-codegen]), the optimizer may assume that unwinding across Rust |
| 10 | +frames is impossible, which can result in both code-size and runtime speed |
| 11 | +improvements. |
4 | 12 |
|
5 |
| -From the Book: |
| 13 | +## `rustc` codegen and linking |
| 14 | +[rustc-codegen]: #rustc-codegen |
6 | 15 |
|
7 |
| -> By default, when a panic occurs, the program starts unwinding, which means |
8 |
| -> Rust walks back up the stack and cleans up the data from each function it |
9 |
| -> encounters. However, this walking back and cleanup is a lot of work. Rust, |
10 |
| -> therefore, allows you to choose the alternative of immediately aborting, |
11 |
| -> which ends the program without cleaning up. Memory that the program was using |
12 |
| -> will then need to be cleaned up by the operating system. |
| 16 | +`rustc` provides two supported runtime strategies: |
13 | 17 |
|
14 |
| -`rustc` option: `-C panic=<foo>` |
| 18 | +* `-C panic=unwind` - this links against `panic_unwind` and ensures that |
| 19 | + unwinding across the compiled frames will perform all appropriate clean-up. |
| 20 | + In particular, `drop` will be called for live `Drop` objects. |
| 21 | +* `-C panic=abort` - this links against `panic_abort`, and optimizes with the |
| 22 | + assumption that frames cannot be unwound. Since unwinding does not occur with |
| 23 | + this runtime, it is impossible to catch a `panic!` using `catch_unwind`. |
15 | 24 |
|
16 |
| -`panic=abort` |
17 |
| -`panic=unwind` (default) |
| 25 | +This codegen option will default to `unwind` if not specified, and the value is |
| 26 | +encoded into the crate metadata. |
| 27 | + |
| 28 | +Linking against the actual panic runtime is performed lazily, so that if |
| 29 | +different crates specify different runtimes, the `panic_abort` runtime is |
| 30 | +preferred. This ensures that `panic!` cannot cause a soundness hole by |
| 31 | +unwinding across Rust frames compiled with `panic=abort`. |
| 32 | + |
| 33 | +## Custom panic runtimes |
| 34 | + |
| 35 | +<!-- XXX - is this attribute now stable? --> |
| 36 | + |
| 37 | +In addition to the runtimes provided by the standard library, users may |
| 38 | +implement their own panic runtime. The `#![panic_runtime]` attribute indicates |
| 39 | +that a crate is a runtime implementation of panics. |
| 40 | + |
| 41 | +The actual API of panic runtimes is not currently specified. |
18 | 42 |
|
19 | 43 | With `panic=abort`:
|
20 | 44 | * Cleanup code (`Drop`) can't be called
|
21 | 45 | * Panics can't be caught with `catch_unwind`
|
22 |
| - |
23 |
| -Cargo unifies panic runtimes |
|
0 commit comments