Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tracking Issue for WebAssembly exception handling #118168

Open
4 of 8 tasks
coolreader18 opened this issue Nov 22, 2023 · 1 comment
Open
4 of 8 tasks

Tracking Issue for WebAssembly exception handling #118168

coolreader18 opened this issue Nov 22, 2023 · 1 comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature.

Comments

@coolreader18
Copy link
Contributor

coolreader18 commented Nov 22, 2023 •
edited
Loading

This is a tracking issue for wasm native exception handling, which would allow panic=unwind to function properly for code targeting wasm.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Unresolved Questions

  • -C target-feature=+exception-handling vs -C panic=unwind -- does one imply the other, or is one of them redundant?
    • panic=unwind should enable exception-handling
  • Should -C llvm-args=-wasm-enable-eh be passed by default on all wasm targets, to be stripped out if the exception-handling target feature is disabled?
    • yes: afaict -wasm-enable-eh does not affect codegen in general, only isel for the wasm.throw instruction.
  • Should exception-handling instructions (e.g. from prebuilt libstd) be stripped out if panic=abort? If so, by whom? wasm-ld? wasm-opt does currently implement a --strip-eh pass; maybe that's good enough if users want to target wasm MVP?
    • this problem is similar to the one that atomics (Tracking issue for WebAssembly atomics #77839) faces, of a single prebuilt libstd coming into conflict with some users needing backwards compatibility with wasm-MVP and others wanting to use more recently stabilized features

Implementation history
@coolreader18 coolreader18 added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Nov 22, 2023
@coolreader18
Copy link
Contributor Author

coolreader18 commented Nov 22, 2023 •
edited
Loading

(The unresolved questions might have obvious answers that I couldn't see, those are just the questions I came up with in poking around and trying to add wasm32 support to libpanic_unwind)

@white-axe white-axe mentioned this issue Jan 2, 2024
Merged
5 tasks
@coolreader18 coolreader18 mentioned this issue Feb 22, 2024
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 5, 2024
@matthiaskrgr
Rollup merge of rust-lang#121438 - coolreader18:wasm32-panic-unwind, …
73ab3c7 
…r=cuviper

std support for wasm32 panic=unwind

Tracking issue: rust-lang#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...
```
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Mar 11, 2024
@workingjubilee
Rollup merge of rust-lang#121438 - coolreader18:wasm32-panic-unwind, …
1279830 
…r=cuviper

std support for wasm32 panic=unwind

Tracking issue: rust-lang#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...
```
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 11, 2024
@rust-timer
Unrolled build for rust-lang#121438
08711d5 
Rollup merge of rust-lang#121438 - coolreader18:wasm32-panic-unwind, r=cuviper

std support for wasm32 panic=unwind

Tracking issue: rust-lang#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...
```
@PgBiel PgBiel mentioned this issue Jun 18, 2024
Open
@TrueDoctor TrueDoctor mentioned this issue Jul 23, 2024
Merged
@MichaReiser MichaReiser mentioned this issue Aug 14, 2024
Draft
@coolreader18 coolreader18 mentioned this issue Oct 8, 2024
Merged
tgross35 added a commit to tgross35/rust that referenced this issue Oct 12, 2024
@tgross35
Rollup merge of rust-lang#131418 - coolreader18:wasm-exc-use-stdarch,…
ca983f3 
… r=bjorn3

Use throw intrinsic from stdarch in wasm libunwind

Tracking issue: rust-lang#118168

This is a very belated followup to rust-lang#121438; now that rust-lang/stdarch#1542 is merged, we can use the intrinsic exported from `core::arch` instead of defining it inline. I also cleaned up the cfgs a bit and added a more detailed comment.
tgross35 added a commit to tgross35/rust that referenced this issue Oct 13, 2024
@tgross35
Rollup merge of rust-lang#131418 - coolreader18:wasm-exc-use-stdarch,…
415e61c 
… r=bjorn3

Use throw intrinsic from stdarch in wasm libunwind

Tracking issue: rust-lang#118168

This is a very belated followup to rust-lang#121438; now that rust-lang/stdarch#1542 is merged, we can use the intrinsic exported from `core::arch` instead of defining it inline. I also cleaned up the cfgs a bit and added a more detailed comment.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 13, 2024
@rust-timer
Unrolled build for rust-lang#131418
f4a1363 
Rollup merge of rust-lang#131418 - coolreader18:wasm-exc-use-stdarch, r=bjorn3

Use throw intrinsic from stdarch in wasm libunwind

Tracking issue: rust-lang#118168

This is a very belated followup to rust-lang#121438; now that rust-lang/stdarch#1542 is merged, we can use the intrinsic exported from `core::arch` instead of defining it inline. I also cleaned up the cfgs a bit and added a more detailed comment.
@kleisauke kleisauke mentioned this issue Oct 16, 2024
Open
@alexcrichton alexcrichton mentioned this issue Oct 31, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@coolreader18