-
Notifications
You must be signed in to change notification settings - Fork 758
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
Support Asyncify + Try-Catch [Can't build web-gphoto2 with -fwasm-exceptions instead of -fexceptions] #4470
Comments
I think that is this: binaryen/src/passes/Asyncify.cpp Lines 995 to 999 in 0604422
So the issue is supporting the Try control flow structure in that pass. It needs special handling for each one since it needs to be able to resume execution back into the middle. For Try, the hard part would be to get back into the catch when rewinding... maybe we could construct and throw another exception just to get there? Or maybe we should move the code out of the catch, and guard it with a condition, so it can be reached either from the catch or from a resume, something like that. |
@RReverser did you find a work around (other than just sticking with |
This code here seems sufficient enough to reproduce the problem: #include <iostream>
#include <stdexcept>
__attribute__((import_module("env"), import_name("external_async_function")))
void external_async_function();
int main() {
try {
throw std::invalid_argument("test");
}
catch(const std::invalid_argument& e) {
std::cout << "caught" << std::endl;
}
std::cout << "before" << std::endl;
external_async_function();
std::cout << "after" << std::endl;
return 0;
} compiling with:
|
Tested the same code with the latest versions (as follows) but I seem to hit the same error.
|
Yes, no work has been done on this so far. The work that would need to be done is mentioned in #4470 (comment) |
@RReverser this might be possible soon: #5475 |
@allsey87 fwiw I am porting a game of my own from desktop to wasm and I would like to use wasm exceptions but, so far, I will also need ASYNCIFY. So this support would be great. |
Add unwinding and recover support for wasm using WebAssembly exception handling. This still has a few gotchas: * Many WASI systems don't support exception handling yet. For example, see: bytecodealliance/wasmtime#2049 * Asyncify doesn't support wasm exception handling: WebAssembly/binaryen#4470 This means it's not possible to use goroutines together with panic/recover. * The current way that exceptions are implemented pretend to be C++ exceptions, but work slightly differently. If C++ code is called (for example through CGo) that raises an exception, that exception will be eaten by TinyGo and not be propagated. This is fixable, it just hasn't been implemented (because we don't actually support C++ right now). I hope that these issues will be resolved over time. At least for now, people who need `recover()` have a way to use it.
Add unwinding and recover support for wasm using WebAssembly exception handling. This still has a few gotchas: * Many WASI systems don't support exception handling yet. For example, see: bytecodealliance/wasmtime#2049 * Asyncify doesn't support wasm exception handling: WebAssembly/binaryen#4470 This means it's not possible to use goroutines together with panic/recover. * The current way that exceptions are implemented pretend to be C++ exceptions, but work slightly differently. If C++ code is called (for example through CGo) that raises an exception, that exception will be eaten by TinyGo and not be propagated. This is fixable, it just hasn't been implemented (because we don't actually support C++ right now). I hope that these issues will be resolved over time. At least for now, people who need `recover()` have a way to use it.
Add unwinding and recover support for wasm using WebAssembly exception handling. This still has a few gotchas: * Many WASI systems don't support exception handling yet. For example, see: bytecodealliance/wasmtime#2049 * Asyncify doesn't support wasm exception handling: WebAssembly/binaryen#4470 This means it's not possible to use goroutines together with panic/recover. * The current way that exceptions are implemented pretend to be C++ exceptions, but work slightly differently. If C++ code is called (for example through CGo) that raises an exception, that exception will be eaten by TinyGo and not be propagated. This is fixable, it just hasn't been implemented (because we don't actually support C++ right now). I hope that these issues will be resolved over time. At least for now, people who need `recover()` have a way to use it.
web-gphoto2 builds with pthreads, Asyncify, exceptions and LTO, and I'm not sure which combo is specifically problematic here, but the end result is that it crashes when trying to switch from
-fexceptions
to-fwasm-exceptions
:A branch that's failing can be checked out from here: https://github.com/GoogleChromeLabs/web-gphoto2/tree/fwasm-exceptions. It should be pretty reproducible as it uses Docker, so all you need to do is run
./build.sh
in the checkout folder.The text was updated successfully, but these errors were encountered: