Wasm EH: Export exception/tag

[bkotsopoulossc]

I've been trying to use wasm exception handling with a recent version of emscripten.

 % ./upstream/emscripten/emcc --version
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.0.0 (3fd52e107187b8a169bb04a02b9f982c8a075205)

The old EH spec introduced a new thing called a "Tag" here, and the newer one has the same concept but calls it an "exception" here, but it essentially seems the same.

When I build with -fwasm-exceptions, the resulting module has a tag section, which is good. But if I inspect the exports, I don't see the exported tag/exception entry from here. This export is important to be able to catch a wasm exception in JS, and get access to the exception pointer. Without this, I don't see any way to get access to the C++ exception contents.

Is this expected, that the exception export is missing? What is required to add it?

[sbc100]

I would hope that you could just export it by adding it to EXPORTED_FUNCTIONS (this settings is somewhat misnamed and really means "exported symbols"... also remember to add an extra "_" to the beginning of the C symbol name to it would be EXPORTED_FUNCTIONS=___cpp_exception). If that doesn't work (I've never tried it) you can try --Wl,--export=__cpp_exception (without any extra underscore).

[bkotsopoulossc]

For the first, I get:

emcc: error: undefined exported symbol: "___cpp_exception" [-Wundefined] [-Werror]

For the second, I get:

clang-14: error: unsupported option '--Wl,--export=__cpp_exception'
emcc: error: '/Users/brad.kotsopoulos/Snapchat/Dev/emsdk/upstream/bin/clang++ -target wasm32-unknown-emscripten -DEMSCRIPTEN -fvisibility=default -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -D__EMSCRIPTEN_major__=3 -D__EMSCRIPTEN_minor__=0 -D__EMSCRIPTEN_tiny__=0 -D_LIBCPP_ABI_VERSION=2 -Werror=implicit-function-declaration -Xclang -iwithsysroot/include/SDL --sysroot=/Users/brad.kotsopoulos/Snapchat/Dev/emsdk/upstream/emscripten/cache/sysroot -Xclang -iwithsysroot/include/compat -fwasm-exceptions --Wl,--export=__cpp_exception bazel/hello-world/hello-world.cc -c -o /var/folders/8y/8sw1v9j96w53_tyy9wc6dq9h0000gp/T/emscripten_temp_9udtby74/hello-world_0.o' failed (returned 1)

[sbc100]

Sorry, there should only be one leading - in -Wl,--export=__cpp_exception

[aheejin]

The old EH spec introduced a new thing called a "Tag" here, and the newer one has the same concept but calls it an "exception" here, but it essentially seems the same.

As I said in the EH repo, the latter is not the newer one. It is outdated at the moment; please refer to the explainer.

When I build with -fwasm-exceptions, the resulting module has a tag section, which is good. But if I inspect the exports, I don't see the exported tag/exception entry from here. This export is important to be able to catch a wasm exception in JS, and get access to the exception pointer. Without this, I don't see any way to get access to the C++ exception contents.

Does #16033 (comment) work?

[bkotsopoulossc]

Yes that did! Maybe for convenience, we auto-export the symbol if -fwasm-exceptions are defined? It's hard to image a use case for exceptions where you absolutely do not want the export right? Also I wonder if we could rename/alias it in the export table so it's called something simple like exception?

[sbc100]

Excuse my ignorance, but can you show me how the exported tag is used from JS? How does it enable extracting the pointer?

[bkotsopoulossc]

Like so:

const instantiatedWasm = await WebAssembly.instantiateStreaming(...)

// ...

try {
  Module.someThingThatThrows()
} catch (e)
  if (e instanceof WebAssembly.Exception) {
    // get access to a pointer on the wasm heap that represents the C++ exception object
    const wasmExceptionPtr = e.getArg(instantiatedWasm.instance.exports.__cpp_exception, 0)

    // call some custom hook back into wasm to access the underlying exception object based on the pointer
    const message = Module.getExceptionMessage(wasmExceptionPtr)
    console.log(message)
  }
}

[sbc100]

I see, thanks. So that tag is requires to extract the pointer.

I think there may be users who only care about exceptions in C++ and don't need/want to do this kind of catching from the JS side, so maybe exporting by default is not what we want, but I guess we should see how common that is.

Certainly there should be an easy way to export this for users that want access to it. I think if we make adding it EXPORTED_FUNCTIONS work that would make the most sense.

[bkotsopoulossc]

My opinion is that wanting the ability to catch an exception in JS from wasm is more common than not, but hard to say.

The only way you wouldn't be interested in catching in a C++ codebase is if you had a try-catch on the c++ side for every API call that caught every type of exception and didn't re-throw.

But, maybe it's just a matter of documenting it here https://emscripten.org/docs/porting/exceptions.html#webassembly-exception-handling-proposal. This took me a bit of digging around to figure out how these things are supposed to piece together

[bkotsopoulossc]

So that tag is requires to extract the pointer.

Exactly. At least that is my understanding. However, I tried to use the same trick documented here from JS. With emscripten EH, taking the pointer from JS, calling back into wasm and casting it from int->exception_ptr allows you to access the underlying exception. With wasm EH, this exact same technique gives memory access out of bounds. So I'm not sure if there is something different about the pointer, or where it points in the heap, or if I need to add/subtract some offset or something, or if the exception object has been de-allocated, or something. We expect this to work, right?

[sbc100]

Wasm EH is still very new.. I'm not sure we have any examples yet of how to extract the underlying C++ pointer from JS.. but in theory it should be possible, at least in the long term.

Perhaps there is already test that does this but I'm not aware of it? If not perhaps we could modify of of the existing tests to show how this can work? @aheejin?

[bkotsopoulossc]

There's a test to get the pointer out here, but the pointer isn't used for anything in particular. I'm mostly interested in using the pointer back in wasm to access the exception object

[sbc100]

Sounds like we just need to extend that test to show the pointer is valid (points to a C++ object in wasm memory).

[aheejin]

Sorry for the delayed response! Can you post the reproducer and the command line you built the program with, which runs successfully with Emscripten EH but not with Wasm EH?