-
Notifications
You must be signed in to change notification settings - Fork 176
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
Add Support for WASM Exceptions #334
Comments
The rough plan is to look at Emscripten's port of libunwind to see if it can be either ported to upstream LLVM, or if not, ported to wasi-sdk. I don't know of anyone working on this yet. It's also worth noting that Wasm Exceptions are not yet standardized; currently the proposal is in phase 3. |
We hope to have an initial contribution to WAMR with exception support in the next few months. There is such a swathe of C++ software in-particular that is excluded from the WASM ecosystem because of the lack of exception support. It would be awesome to see a solution. Although, digging through the code that is generated by the emscripten tool chain we can see, that at least for C++ it generates a single WASM exception |
As Dan mentioned, the easy part is enabling exceptions in the compiler (e.g. passing To see that current differences from upstream that were made in emscripten you can take a look here: https://github.com/emscripten-core/emscripten/blob/main/system/lib/libcxxabi/readme.txt. Specifically check out the link at the end that shows you the diffs from upstream llvm 16: llvm/llvm-project@llvmorg-16.0.4...emscripten-core:emscripten-libs-16 |
Whooha... Rockstar's both of you, and I've got some reading to do. Thanks for the pointers. Let me take a look. |
There's also a draft PR with initial support for this in #198, which you may be interested in. |
I have a plan to upstream the current libc++abi/libunwind changes to the upstream LLVM. I think it can happen within a couple months if having this is a priority; the timeline can depend on the receptions from the reviewers though. By the way there is a discussions going on (WebAssembly/exception-handling#280) which can change the spec itself. I don't think the library side will change much with this though. |
Thank you for the wait. Wasm EH's libcxxabi/libunwind changes have now been upstreamed: |
What does
thx |
Just wanted to check, would WASM exceptions make sense for implementing C |
I think you should be able to lower SjLj to exceptions. |
Indeed, llvm already uses wasm exception to implement SJLJ, when wasm exceptions are enabled, so it should just work once we enable exceptions. |
Indeed, wasm exceptions is how we've always envisioned |
Thanks for confirming! I implemented stack unwind for wazero and look forward to trying it out with wasi SDK (from my reading of the thread it isn't quite ready yet for use with the published SDKs) |
I found that llvm 17 was branched off end of June and above exception patches were merged mid September, so we need to wait for llvm 18 (should branch off today, first RC on Friday) or upgrade to a git version. |
The Languages aren't used to dealing with WASM exception instructions. Instead they traditionally use setjmp / longjmp, C++ is a good example of this. Therefore the language's supporting library (also confusingly called the C++ runtime) needs to be updated to use exception handling. When the C++ compiler encounters an exception in the code you are attempting to compile, behind the scenes it generates calls to it's runtime library to implement the exception handling. It is inside the runtime library that the exception instructions are used. The error your seeing is an error generated by WASI-SDK, which bundles the C++ runtime library, the version of the library supplied by WASI-SDK doesn't include the three functions listed above - which are all designed for exception handling. So when you compile C++ with an exception in your code, the compiler generates it faithfully, with calls to functions in the C++ runtime library which do not exist, this is why, at link time you get the error message you mentioned. The Emscripten folks have worked on this and have an update which includes the C++ runtime functions we're missing. I understand they were hoping to upstream this to LLVM, and then WASI-SDK would be able to pull this down. - I'm not sure of the current state of this work, @sunfishcode and @aheejin and, I think the best folks to be able to help on that front. |
That is a great explanation, thank you. |
The library code has been already upstreamed, as I commented in #334 (comment). But given that Emscripten uses our custom build system and not the LLVM's CMake build system, how it works well with the native LLVM has not been well tested and you might need some adjustment on the build files. I'm not familiar with what build system WASI uses (Is that the LLVM's or something separate?), but that will require changes as well. For example, from libunwind we only use |
do you mean to use saveSetjmp getTempRet0 etc for WASI as well? |
Right, and this seems to have been moved to compiler-rt in Emscripten: https://github.com/emscripten-core/emscripten/blob/main/system/lib/compiler-rt/emscripten_setjmp.c Even though the file name says 'emscripten', some of the functions in there are also used by Wasm SjLj handling (which is, SjLj handling using the instructions in the Wasm EH proposal) That file was newly added in Emscripten and didn't come from the compiler-rt in LLVM. I understand this is getting confusing somewhat, which I think stemmed from that Emscipten uses its custom build system.. I guess we should consider making LLVM's CMake system to reflect the Emscripten setup. In the meantime, this is the list of library files created/modified for Wasm EH in Emscripten: compiler-rt: libc++abi: libunwind: |
thank you. |
There are plans to add support for exceptions in WAMR. Are there any plans to add support to the WASI-SDK tool chain to support Native WASM Exceptions?
(edit: fix link)
The text was updated successfully, but these errors were encountered: