std support for wasm32 panic=unwind

[coolreader18]

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:

#[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");
    }
}

;; 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...

[rustbot]

r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[coolreader18]

Also, though this is more of a future concern, idk if a panic=unwind std would be able to run nicely in a panic=abort binary atm - if the user is trying to keep backwards compatibility to wasm MVP, llvm or something would have to strip the try instructions from the end result.

[bjorn3]

Maybe add a new rust intrinsic which lowers to this LLVM intrinsic when using the LLVM backend?

[coolreader18]

I think I wanna put it in stdarch, alongside the other wasm instructions. A full extern "rust-intrinsic" intrinsic shouldn't be necessary.

[coolreader18]

rust-lang/stdarch#1542

[rustbot]

This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp.

[coolreader18]

Ok, now wasi uses libunwind, while -unknown still uses wasm.throw directly. It does seem like the scheme that LLVM implements is a tooling convention (so, not just LLVM's specific implementation) but it does say it's for C++ specifically, and says other languages should have distinct tags. However, doing that means (unless I'm reading the exception-handling proposal wrong) that exceptions caught in a different language can't be cleaned up. But maybe that's fine, for now.

[coolreader18]

Oh, actually, if we had a distinct tag for panics it would just mean that a C++ exception would skip catch_unwind. Which is fine, if I'm reading the C-unwind rfc correctly.

As noted in the summary, if a Rust frame containing a pending catch_unwind call is unwound by a foreign exception, the behavior is undefined for now.

If we really want to process a C++ exception with catch_unwind in the future, we could just implement the itanium wasm EH scheme in library/unwind and codegen a catch $cpp_exc_tag for r#try. Once llvm supports that.

[coolreader18]

Actually, knowing that, do you think wasi even needs llvm's libunwind? We can handle it just fine ourselves, obviously, and it will indeed cause UB at catch_unwind, but that's fine, and that'll be fixable if we want to once LLVM lets you specify other tags.

[coolreader18]

I've convinced myself I think, lol

[cuviper]

I'm not clear, is this waiting on the stdarch change, or vice versa?

[coolreader18]

Vice versa - the stdarch PR will fail until this is in nightly.

[cuviper]

@bors r+

[bors]

📌 Commit c7fcf43 has been approved by cuviper

It is now in the queue for this repository.