Clarify state of exception handling
Opened this issue · 1 comments
I have spent quite some time trying to build a libc++ with exception handling enabled against wasix-libc.
Eventually I concluded I could not get it done, and based on the information I could find I am not even sure that the Wasmer runtime would support it at all (I don't see an enable-exceptions CLI option).
What I eventually got stuck on is that in libc++abi, there is no _Unwind_RaiseException symbol available, even when built with -fwasm-exceptions. I figured such a symbol should be provided by libunwind, but LLVM's libunwind does not seem to accept wasm as a target architecture.
Apparently, emscripten has a working libunwind, but I am guessing this one wouldn't be possible to get running in pure WASM.
I also noticed that the examples Makefile of this repo uses asyncify via binaryen, to somehow make stack unwinding possible. I don't know how that works, but could there maybe be a possibility to build a working libunwind on top of this stack unwinding principle? Maybe it could even be used to implement exception handling via SJLJ without using native WASM instructions?
It seems to me like the pieces to the puzzle are there and we are possibly quite close to exception support via WASIX or even via WASI's exception proposal without WASIX required. I hope you can shed some light on the situation as the available info is very scattered at the moment.
Wasmer does not support the Exception extension for now. That's why you don't see --enable-exceptions on the CLI indeed.
I am not aware on any mecanism to have a _Unwind_RaiseException with asyncify. WASIX does support setjmp(...) and longjmp(...), so it might be enough to implement exception? I'm unsure how emscripten impleted them.