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.

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

Stabilize `std::arch::wasm32::unreachable` #61119

Open
pepyakin opened this issue May 24, 2019 · 8 comments

Comments

Projects
None yet
5 participants
@pepyakin
Copy link
Contributor

commented May 24, 2019

This is a tracking issue to stabilize std::arch::wasm32::unreachable
The tentative signature is:

fn unreachable() -> !;

Semantics

This intrinsic represents instruction that is present in the MVP of WebAssembly: unreachable.

From the surface it is a simple instruction: it doesn't take any arguments nor return anything. Upon the execution it generates a trap, which terminates the execution of wasm immediately returning control to the embedder with an error. There are no way to catch a trap at the moment.

Note that technically a WebAssembly instance can be used after a trap. However, Rust doesn't guarantee that such a module is usable after a trap. For example, there is no guarantee that the stack will be reset to initial values or that any destructors be executed.

Stabilization in Rust

In a way, this intrinsic is similar to the currently stabilized std::process::abort function. In fact, std::process::abort is lowered to the unreachable instruction for wasm32-unknown-unknown - this is totally makes sense since wasm32-unknown-unknown doesn't make any assumptions of the host environment. However, there is a problem with std::process::abort, it is only available in std. Consider how you would implement a panic handler in WebAssembly for no_std mode when a trap is required:

#[panic_handler]
fn panic_handler(_: &PanicInfo) -> ! {
    unsafe {
        intrinsics::abort();
    }
}

This works, however, it requires #![feature(core_intrinsics)]. Here are other ways and why they are not appropriate:

  1. e.g. safe division by zero - requires panic, thus recursive. Unsafe division might work, but then it would require loop { } which might be a problem.
  2. e.g. make an access to the address 0xFFFFFFFF assuming that it is not accessible. Doesn't work if the module genuinely allocates 4GiBs. I guess that optimizer also might be able to figure out that it is being tricked with respective consequences.
  3. e.g. call_indirect suffer from the similar issues.
  4. If the host is known (which is likely), it might be possible to introduce a special host function sole function of which is just trap. But that feels hacky and clumsy as well.

Stabilization of unreachable will allow implementing the panic handler in no_std environments on stable.

cc @alexcrichton @sunfishcode

@alexcrichton

This comment has been minimized.

Copy link
Member

commented May 24, 2019

@rfcbot fcp merge

Seems reasonable to me to stabilize!

@rfcbot

This comment has been minimized.

Copy link

commented May 24, 2019

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@SimonSapin

This comment has been minimized.

Copy link
Contributor

commented May 24, 2019

Is this the same as core::intrinsics::abort? Should we have a stable portable function for this in libcore?

@alexcrichton

This comment has been minimized.

Copy link
Member

commented May 24, 2019

It is indeed the same, but there have been concerns about stabilizing intrinsics::abort historically due to some architectures not actually having an abort instruction (I think it was like msp430 or something like that)

@pepyakin

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2019

I guess almost all of MCUs don't have such an instruction. Maybe @japaric can confirm this?

@rfcbot

This comment has been minimized.

Copy link

commented May 24, 2019

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot

This comment has been minimized.

Copy link

commented Jun 3, 2019

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

Ok great! @pepyakin want to send a PR to stabilize to stdsimd?

bors added a commit that referenced this issue Jun 6, 2019

Auto merge of #61540 - pepyakin:update-stdsimd, r=alexcrichton
Update stdsimd

Ref #61119,  for stabilization of wasm32 `unreachable`

Centril added a commit to Centril/rust that referenced this issue Jun 6, 2019

Rollup merge of rust-lang#61540 - pepyakin:update-stdsimd, r=alexcric…
…hton

Update stdsimd

Ref rust-lang#61119,  for stabilization of wasm32 `unreachable`

bors added a commit that referenced this issue Jun 6, 2019

Auto merge of #61540 - pepyakin:update-stdsimd, r=alexcrichton
Update stdsimd

Ref #61119,  for stabilization of wasm32 `unreachable`

Centril added a commit to Centril/rust that referenced this issue Jun 6, 2019

Rollup merge of rust-lang#61540 - pepyakin:update-stdsimd, r=alexcric…
…hton

Update stdsimd

Ref rust-lang#61119,  for stabilization of wasm32 `unreachable`

bors added a commit that referenced this issue Jun 6, 2019

Auto merge of #61540 - pepyakin:update-stdsimd, r=alexcrichton
Update stdsimd

Ref #61119,  for stabilization of wasm32 `unreachable`

@pepyakin pepyakin referenced this issue Jun 16, 2019

Open

Compile the runtime with a stable toolchain #1252

1 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.