wasm32-emscripten stability issues (exception handling) #98030
Comments
|
cc @tlively who knows most about Rust/Emscripten from the Emscripten side. |
|
One problem here is that we don't have a good way to automatically ensure or even document that users' Emscripten versions are compatible with their Rust versions. New versions of Emscripten breaking things with Rust is WAI because it is not possible for Rust to be compatible with arbitrary Emscripten versions. There have been multiple attempts to improve the documentation situation (emscripten-core/emscripten#14394, rustwasm/book#243, rust-lang/rustup#2791), but none have gone anywhere. Ideally we would find the most compatible Emscripten version every time Rust updates its LLVM, we would document that version clearly both in documentation and in the output of tools like rustup, and we would have rustup automatically install the correct version of Emscripten when installing the wasm32-emscripten backend. We would also want to update the version of Emscripten used in Rust CI (https://github.com/rust-lang/rust/blob/master/src/ci/docker/scripts/emscripten.sh#L23-L24) and fix any subsequent test failures before Rust's LLVM upgrade rolls out to stable. We should add test coverage to Rust for non-default Emscriptent configurations that folks might want to use, such as with different EH options, or building as a dynamic library, or using Asyncify, etc. |
|
The unwinding breakage wasn't an LLVM compatibility issue as far as I can tell, it was due to |
|
Right. More generally, we have to periodically do work on the Rust side to upgrade the known-compatible Emscripten version. In principle we could do that in response to Emscripten changes like the change to |
|
Can you point out which change in libunwind this is about? I don't think we have changed libunwind in a long while, and we didn't touch the API side so far AFAICT. |
|
Hello, I work on Wasm exception handling. I mainly worked on the new Wasm EH proposal and its toolchain support, but I also worked on the old Emscripten EH support for our LLVM backend as well. I am happy to be cc'ed on or review any EH related changes, but I don't know much about Rust or Rust toolchain, with which I may need help. |
Sorry, I was wrong, the change that led to the breaage was emscripten-core/emscripten@b43d3de. |
We can see is that the change that led to the breakage was very minor. I think "we can't guarantee stability" isn't the same as "we won't put any effort into trying not to break things." In particular, if Emscripten CI had shown that removing the If there is a good reason to break the ABI (e.g., fixing a design flaw that can't easily be fixed without an ABI breakage), then at least if it's a known breakage there could be a discussion, documentation of the issue and workarounds, and fixes. |
|
Assuming we can re-add this symbol, along with some kind of test, and some justification as to why we should include it all, I'm happy to see it return. |
|
I will open a PR then. Ideally we can drop it again when the LLVM version of Emscripten is next updated (since the next version of Rust won't need the patch). |
Emscripten's LLVM is continuously updated, usually multiple times per day. Did you mean Rust's LLVM? |
|
I was thinking about the major version of LLVM. But I guess the issue of when we can remove the patch is maybe a bit complicated. Anyways just having a comment to say "remove this some day" may be okay. |
|
Emscripten (as far as I can tell) uses the latest LLVM nightly (currently 15.x), so it will have a higher major version than Rust's LLVM (currently 14.0). |
There have been repeated issues with Rust support for the wasm32-emscripten target, particularly involving exception handling (e.g., #97888 #85821), but also involving dynamic linking (e.g., #80775, #92738). Building a rust program as a wasm32-emscripten dynamic library is currently a very delicate business which I would like to see get better.
In my opinion, the main issue here is one of coordination between the Emscripten and rust teams. Ideally I think the following changes would be made:
Emscripten supports two different error handling ABIs: Emscripten exception handling, and wasm exception handling. Wasm exception handling is more efficient, but it is only supported on Safari >= 15.2 which is of concern because ~3% of web users are on older Safari versions, particularly people with old iphones. Ideally, Rust would be able to support both ABIs. In particular, in the case where we are building a dynamically linked library for emscripten (e.g., for Python packages) the ABI used by the module has to match the ABI that the main module was built with.
We would need some configuration that allows the user to choose between abort, emscripten exceptions, and wasm exceptions. I think picking abort as the default is the most reasonable thing to do because this matches Emscripten's behavior: by default C++ exceptions are not supported, but one can opt in to Emscipten eh with
-fexceptionsor wasm eh with-fwasm-exceptions.It was suggested that we need a major change proposal, which I think may be a good idea. I am willing to write one after we have a discussion and figure out what should be done. I don't understand much about the Rust consensus process nor really much about error handling so I would have to learn a bit first.
@Jules-Bertholet @Amanieu @brson @nagisa @apiraino @pnkfelix @sbc100 @kripken @aheejin
The text was updated successfully, but these errors were encountered: