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).
2016-04-08 16:18:40 -07:00
|
|
|
//! Implementation of panics via stack unwinding
|
|
|
|
//!
|
|
|
|
//! This crate is an implementation of panics in Rust using "most native" stack
|
|
|
|
//! unwinding mechanism of the platform this is being compiled for. This
|
|
|
|
//! essentially gets categorized into three buckets currently:
|
|
|
|
//!
|
|
|
|
//! 1. MSVC targets use SEH in the `seh.rs` file.
|
2019-10-21 02:46:04 +01:00
|
|
|
//! 2. Emscripten uses C++ exceptions in the `emcc.rs` file.
|
|
|
|
//! 3. All other targets use libunwind/libgcc in the `gcc.rs` file.
|
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).
2016-04-08 16:18:40 -07:00
|
|
|
//!
|
|
|
|
//! More documentation about each implementation can be found in the respective
|
|
|
|
//! module.
|
|
|
|
|
|
|
|
#![no_std]
|
|
|
|
#![unstable(feature = "panic_unwind", issue = "32837")]
|
2021-05-04 23:36:33 -04:00
|
|
|
#![doc(issue_tracker_base_url = "https://github.com/rust-lang/rust/issues/")]
|
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).
2016-04-08 16:18:40 -07:00
|
|
|
#![feature(core_intrinsics)]
|
|
|
|
#![feature(lang_items)]
|
2017-10-22 20:01:00 -07:00
|
|
|
#![feature(panic_unwind)]
|
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).
2016-04-08 16:18:40 -07:00
|
|
|
#![feature(staged_api)]
|
2018-03-29 14:59:13 -07:00
|
|
|
#![feature(std_internals)]
|
2019-12-29 21:16:20 +01:00
|
|
|
#![feature(abi_thiscall)]
|
2019-12-26 10:02:21 -05:00
|
|
|
#![feature(rustc_attrs)]
|
2016-05-23 22:28:15 -07:00
|
|
|
#![panic_runtime]
|
|
|
|
#![feature(panic_runtime)]
|
2021-06-08 11:23:58 -07:00
|
|
|
#![feature(c_unwind)]
|
2020-03-14 11:23:39 +01:00
|
|
|
// `real_imp` is unused with Miri, so silence warnings.
|
|
|
|
#![cfg_attr(miri, allow(dead_code))]
|
|
|
|
|
2018-03-29 14:59:13 -07:00
|
|
|
use alloc::boxed::Box;
|
2019-12-26 19:37:14 +01:00
|
|
|
use core::any::Any;
|
2018-03-29 14:59:13 -07:00
|
|
|
use core::panic::BoxMeUp;
|
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).
2016-04-08 16:18:40 -07:00
|
|
|
|
2019-06-10 08:12:14 -07:00
|
|
|
cfg_if::cfg_if! {
|
2019-11-27 20:39:53 +01:00
|
|
|
if #[cfg(target_os = "emscripten")] {
|
2018-07-16 16:38:56 -07:00
|
|
|
#[path = "emcc.rs"]
|
2020-03-14 11:23:39 +01:00
|
|
|
mod real_imp;
|
2019-10-06 15:26:14 +00:00
|
|
|
} else if #[cfg(target_os = "hermit")] {
|
|
|
|
#[path = "hermit.rs"]
|
2020-03-14 11:23:39 +01:00
|
|
|
mod real_imp;
|
2021-05-31 14:34:23 +02:00
|
|
|
} else if #[cfg(target_os = "l4re")] {
|
|
|
|
// L4Re is unix family but does not yet support unwinding.
|
|
|
|
#[path = "dummy.rs"]
|
|
|
|
mod real_imp;
|
2018-07-16 16:38:56 -07:00
|
|
|
} else if #[cfg(target_env = "msvc")] {
|
|
|
|
#[path = "seh.rs"]
|
2020-03-14 11:23:39 +01:00
|
|
|
mod real_imp;
|
2020-07-06 20:31:12 -07:00
|
|
|
} else if #[cfg(any(
|
|
|
|
all(target_family = "windows", target_env = "gnu"),
|
2020-08-08 02:14:40 -04:00
|
|
|
target_os = "psp",
|
Add SOLID targets
SOLID[1] is an embedded development platform provided by Kyoto
Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support
for SOLID.
# New Targets
The following targets are added:
- `aarch64-kmc-solid_asp3`
- `armv7a-kmc-solid_asp3-eabi`
- `armv7a-kmc-solid_asp3-eabihf`
SOLID's target software system can be divided into two parts: an
RTOS kernel, which is responsible for threading and synchronization,
and Core Services, which provides filesystems, networking, and other
things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on
the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems
(more precisely, systems where only one processor core is allocated for
SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is
traditionally only specified at the source-code level, the ABI is
unique to each implementation, which is why `asp3` is included in the
target names.
More targets could be added later, as we support other base kernels
(there are at least three at the point of writing) and are interested
in supporting other processor architectures in the future.
# C Compiler
Although SOLID provides its own supported C/C++ build toolchain, GNU Arm
Embedded Toolchain seems to work for the purpose of building Rust.
# Unresolved Questions
A μITRON4 kernel can support `Thread::unpark` natively, but it's not
used by this commit's implementation because the underlying kernel
feature is also used to implement `Condvar`, and it's unclear whether
`std` should guarantee that parking tokens are not clobbered by other
synchronization primitives.
# Unsupported or Unimplemented Features
Most features are implemented. The following features are not
implemented due to the lack of native support:
- `fs::File::{file_attr, truncate, duplicate, set_permissions}`
- `fs::{symlink, link, canonicalize}`
- Process creation
- Command-line arguments
Backtrace generation is not really a good fit for embedded targets, so
it's intentionally left unimplemented. Unwinding is functional, however.
## Dynamic Linking
Dynamic linking is not supported. The target platform supports dynamic
linking, but enabling this in Rust causes several problems.
- The linker invocation used to build the shared object of `std` is
too long for the platform-provided linker to handle.
- A linker script with specific requirements is required for the
compiled shared object to be actually loadable.
As such, we decided to disable dynamic linking for now. Regardless, the
users can try to create shared objects by manually invoking the linker.
## Executable
Building an executable is not supported as the notion of "executable
files" isn't well-defined for these targets.
[1] https://solid.kmckk.com/SOLID/
[2] http://ertl.jp/ITRON/SPEC/mitron4-e.html
[3] https://en.wikipedia.org/wiki/ITRON_project
[4] https://toppers.jp/
2021-09-28 11:20:46 +09:00
|
|
|
target_os = "solid_asp3",
|
2021-07-29 20:18:22 +03:00
|
|
|
all(target_family = "unix", not(target_os = "espidf")),
|
2020-07-06 20:31:12 -07:00
|
|
|
all(target_vendor = "fortanix", target_env = "sgx"),
|
|
|
|
))] {
|
2018-07-16 16:38:56 -07:00
|
|
|
// Rust runtime's startup objects depend on these symbols, so make them public.
|
|
|
|
#[cfg(all(target_os="windows", target_arch = "x86", target_env="gnu"))]
|
2020-03-14 11:23:39 +01:00
|
|
|
pub use real_imp::eh_frame_registry::*;
|
2018-07-16 16:38:56 -07:00
|
|
|
#[path = "gcc.rs"]
|
2020-03-14 11:23:39 +01:00
|
|
|
mod real_imp;
|
2020-07-06 20:31:12 -07:00
|
|
|
} else {
|
|
|
|
// Targets that don't support unwinding.
|
2021-11-01 07:11:05 -07:00
|
|
|
// - family=wasm
|
2020-07-06 20:31:12 -07:00
|
|
|
// - os=none ("bare metal" targets)
|
|
|
|
// - os=uefi
|
2021-07-29 20:18:22 +03:00
|
|
|
// - os=espidf
|
2020-07-06 20:31:12 -07:00
|
|
|
// - nvptx64-nvidia-cuda
|
2020-07-31 18:41:25 +12:00
|
|
|
// - arch=avr
|
2020-07-06 20:31:12 -07:00
|
|
|
#[path = "dummy.rs"]
|
|
|
|
mod real_imp;
|
2020-03-14 11:23:39 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
cfg_if::cfg_if! {
|
|
|
|
if #[cfg(miri)] {
|
|
|
|
// Use the Miri runtime.
|
|
|
|
// We still need to also load the normal runtime above, as rustc expects certain lang
|
|
|
|
// items from there to be defined.
|
|
|
|
#[path = "miri.rs"]
|
2018-07-16 16:38:56 -07:00
|
|
|
mod imp;
|
2020-03-14 11:23:39 +01:00
|
|
|
} else {
|
|
|
|
// Use the real runtime.
|
|
|
|
use real_imp as imp;
|
2018-07-16 16:38:56 -07:00
|
|
|
}
|
|
|
|
}
|
2017-10-22 20:01:00 -07:00
|
|
|
|
2020-01-10 00:19:40 +00:00
|
|
|
extern "C" {
|
|
|
|
/// Handler in libstd called when a panic object is dropped outside of
|
|
|
|
/// `catch_unwind`.
|
|
|
|
fn __rust_drop_panic() -> !;
|
2020-03-21 07:50:38 +00:00
|
|
|
|
|
|
|
/// Handler in libstd called when a foreign exception is caught.
|
|
|
|
fn __rust_foreign_exception() -> !;
|
2020-01-10 00:19:40 +00:00
|
|
|
}
|
|
|
|
|
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).
2016-04-08 16:18:40 -07:00
|
|
|
mod dwarf;
|
|
|
|
|
2020-03-02 11:57:30 +00:00
|
|
|
#[rustc_std_internal_symbol]
|
2020-07-16 09:12:59 -04:00
|
|
|
#[allow(improper_ctypes_definitions)]
|
2020-03-02 13:59:20 +00:00
|
|
|
pub unsafe extern "C" fn __rust_panic_cleanup(payload: *mut u8) -> *mut (dyn Any + Send + 'static) {
|
2019-12-26 19:37:14 +01:00
|
|
|
Box::into_raw(imp::cleanup(payload))
|
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).
2016-04-08 16:18:40 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// Entry point for raising an exception, just delegates to the platform-specific
|
|
|
|
// implementation.
|
2020-03-02 11:57:30 +00:00
|
|
|
#[rustc_std_internal_symbol]
|
2022-05-14 02:46:46 +01:00
|
|
|
pub unsafe fn __rust_start_panic(payload: *mut &mut dyn BoxMeUp) -> u32 {
|
2020-12-25 23:37:27 +01:00
|
|
|
let payload = Box::from_raw((*payload).take_box());
|
2019-11-27 20:39:53 +01:00
|
|
|
|
2020-12-25 23:37:27 +01:00
|
|
|
imp::panic(payload)
|
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).
2016-04-08 16:18:40 -07:00
|
|
|
}
|