| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The previous code inside `cfg_if!` wasn't indented, so the conversion to
`cfg_select!` left it not indented. Indent it.
|
|
Migrate the standard library from using the external `cfg_if` crate to
using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from
`library/std/Cargo.toml`, because while the standard library itself no
longer uses `cfg_if`, it also incorporates the `backtrace` crate, which
does.
Migration assisted by the following vim command (after selecting the
full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This
prompts for confirmation on the `} else {` since that can also appear
inside one of the arms. This also requires manual intervention to handle
any multi-line conditions.
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/865
|
|
Add std support to cygwin target
|
|
Make `_Unwind_Action` a type alias, not enum
It's bitflags in practice, so an enum is unsound, as an enum must only have the described values. The x86_64 psABI declares it as a `typedef int _Unwind_Action`, which seems reasonable. I made a newtype first but that was more annoying than just a typedef. We don't really use this value for much other than a short check.
I ran `x check library --target aarch64-unknown-linux-gnu,x86_64-pc-windows-gnu,x86_64-fortanix-unknown-sgx,x86_64-unknown-haiku,x86_64-unknown-fuchsi
a,x86_64-unknown-freebsd,x86_64-unknown-dragonfly,x86_64-unknown-netbsd,x86_64-unknown-openbsd,x86_64-unknown-redox,riscv64-linux-android,armv7-unknown-freebsd` (and some more but they failed to build for other reasons :D)
fixes #138558
r? workingjubilee have fun
|
|
It's bitflags in practice, so an enum is unsound, as an enum must only
have the described values. The x86_64 psABI declares it as a `typedef
int _Unwind_Action`, which seems reasonable. I made a newtype first but
that was more annoying than just a typedef. We don't really use this
value for much other than a short check.
|
|
|
|
Interface
This commit does not patch libc, stdarch, or cc
|
|
|
|
|
|
Co-authored-by: Kleis Auke Wolthuizen <github@kleisauke.nl>
|
|
Since the stabilization in #127679 has reached stage0, 1.82-beta, we can
start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!`
and `ptr::addr_of_mut!` can stop allowing the unstable feature.
I intentionally did not change any documentation or tests, but the rest
of those macro uses are all now using `&raw const` or `&raw mut` in the
standard library.
|
|
In https://github.com/rust-lang/rust/pull/124748, I mistakenly conflated
"not SjLj" to mean "ARM EHABI", which isn't true, watchOS armv7k
(specifically only that architecture) uses a third unwinding method
called "DWARF CFI".
|
|
The code is written in a way to support 32-bit iOS and tvOS ARM devices,
for future compatibility even though we currently only have a target for
32-bit iOS ARM.
|
|
And remove the libc crate when it isn't needed
|
|
|
|
std support for wasm32 panic=unwind
Tracking issue: #118168
This adds std support for `-Cpanic=unwind` on wasm, and with it slightly more fleshed out rustc support. Now, the stable default is still panic=abort without exception-handling, but if you `-Zbuild-std` with `RUSTFLAGS=-Cpanic=unwind`, you get wasm exception-handling try/catch blocks in the binary:
```rust
#[no_mangle]
pub fn foo_bar(x: bool) -> *mut u8 {
let s = Box::<str>::from("hello");
maybe_panic(x);
Box::into_raw(s).cast()
}
#[inline(never)]
#[no_mangle]
fn maybe_panic(x: bool) {
if x {
panic!("AAAAA");
}
}
```
```wat
;; snip...
(try $label$5
(do
(call $maybe_panic
(local.get $0)
)
(br $label$1)
)
(catch_all
(global.set $__stack_pointer
(local.get $1)
)
(call $__rust_dealloc
(local.get $2)
(i32.const 5)
(i32.const 1)
)
(rethrow $label$5)
)
)
;; snip...
```
|
|
|
|
|
|
The `unwinding` crate supports processing unwinding data, and is written
entirely in Rust. This allows it to be ported to new platforms more
easily than using the llvm-based `libunwind`.
While `libunwind` is very well supported on major targets, it is
difficult to use on other targets. SGX is an example of this where Rust
carries custom patches in order to enable backtrace support.
This adds an alternative for supported architectures. Rather than
providing a custom target, `unwinding` allows for a solution that is
completely written in Rust.
This adds `xous` as the first consumer, and forthcoming patches will
modify libstd to take advantage of this.
Signed-off-by: Sean Cross <sean@xobs.io>
|
|
This bring unwind and personality code more in line with strict-provenance
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reduce exceptions overallocation on non Windows x86_64
Addressing https://github.com/rust-lang/rust/pull/103894#discussion_r1020950196
|
|
Addressing https://github.com/rust-lang/rust/pull/103894#discussion_r1020950196
|
|
That change had been lost during rebase
|
|
This fixes unwinding on `aarch64-*-windows-gnu*`.
|
|
|
|
|
|
This ensures that there are no calls to `C-unwind` function in libunwind.
|
|
libunwind: readd link attrs to _Unwind_Backtrace
It seems the removal of these in 1c07096a45a15de64216f12ec726333870e372b1 was unintended; readding them fixes the build.
fixes rust-lang/rust#93349
r? `@alexcrichton`
|
|
|
|
It seems the removal of these in
1c07096a45a15de64216f12ec726333870e372b1 was unintended; readding them
fixes the build.
fixes rust-lang/rust#93349
|
|
|
|
This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:
* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
unwind". This fixes a longstanding soundness issue where if you
`panic!()` in an `extern "C"` function defined in Rust that's actually
UB because the LLVM representation for the function has the `nounwind`
attribute, but then you unwind.
* Whether or not a function unwinds now mainly considers the ABI of the
function instead of first checking the panic strategy. This fixes a
miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
can still unwind.
* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
reimplemented. Previously this was done as a small tweak during MIR
generation, but this has been moved to a separate and dedicated MIR
pass. This new pass will, for appropriate functions and function
calls, insert a `cleanup` landing pad for any function call that may
unwind within a function that is itself not allowed to unwind. Note
that this subtly changes some behavior from before where previously on
an unwind which was caught-to-abort it would run active destructors in
the function, and now it simply immediately aborts the process.
* The `#[unwind]` attribute has been removed and all users in tests and
such are now using `C-unwind` and `#![feature(c_unwind)]`.
I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
|
|
|
|
|
|
|
|
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
|
|
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
|
|
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
|
|
|
