How can i get native WASM exception handling to work

[major-mayer]

Hi everybody,
i try to use native WASM exception handling because recent browser version should now be compatible.

For this my CMakeLists.txt that contains all the link and compile options looks like this (reduced of course)

target_compile_options(mwNGSPWASM PRIVATE 
	-g2 
	-pthread 
	-fwasm-exceptions  
	-O0 #reduce code size
	)

target_link_options(mwNGSPWASM PUBLIC 
        -fwasm-exceptions
	-sEXPORT_EXCEPTION_HANDLING_HELPERS=1  #https://github.com/emscripten-core/emscripten/blob/f08ae1c1d30954ae77802f8ea92638b22b4ff4ee/src/settings.js#L686
	-sDISABLE_EXCEPTION_THROWING=0
	-O0	# Hopefully reduces link time
        -g2 #don't use -g for now as the DWARF debug infos take to much memory to generate (40gb +)
		--profiling-funcs #Preserve function names in profiling, but otherwise minify whitespace and names as we normally do in optimized builds
        -gsource-map 
		# -sABORT_ON_WASM_EXCEPTIONS=1 # maybe this gives us a stack trace, when an exception happens https://github.com/emscripten-core/emscripten/issues/13868
        -lembind   # Links against embind library
        -sLLD_REPORT_UNDEFINED #more detailed diagnostics when symbols are undefined at link time
        -sINITIAL_MEMORY=65536000
        -sNO_DISABLE_EXCEPTION_CATCHING 
        -sPTHREAD_POOL_SIZE=8
        -sASSERTIONS=1 
		-sDEMANGLE_SUPPORT=1
		-pthread 
		--no-entry # otherwise wasm-ld complains about a missing entry point, but we call the functions from JS anyway
		--preload-file assets
		-Wl,-error-limit=0
		-sFULL_ES2 # full OpenGL ES 3 support
		-sMIN_WEBGL_VERSION=2# only target webgl2 
		-sMAX_WEBGL_VERSION=2
		-sOFFSCREEN_FRAMEBUFFER=1 
		-sEXPORTED_RUNTIME_METHODS=FS
		)

However, when i try to build my project using this settings, i always get the following error message:

[build] wasm-ld: error: symbol exported via --export not found: __cxa_is_pointer_type
[build] wasm-ld: error: symbol exported via --export not found: __cxa_can_catch
[build] em++: error: '/home/laurenz/checkouts/emsdk/upstream/bin/wasm-ld -o Binaries/build/mwNGSPWASM.wasm -error-limit=0 [... many includes ...]-L/home/laurenz/checkouts/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten /home/laurenz/checkouts/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libfreetype.a /home/laurenz/checkouts/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/crtbegin.o --whole-archive -lembind-rtti --no-whole-archive -lGL-mt-webgl2-ofb -lal -lhtml5 -lc_optz-mt-debug -lstubs-debug -lnoexit -lc-mt-debug -ldlmalloc-mt -lcompiler_rt-mt -lc++-mt-except -lc++abi-mt-except -lunwind-mt-except -lsockets-mt -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-cxx-exceptions -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -mllvm -wasm-enable-eh -mllvm -exception-model=wasm --allow-undefined-file=/tmp/tmppdrvn2lr.undefined --import-memory --shared-memory --export-if-defined=_emscripten_thread_init --export-if-defined=_emscripten_thread_exit --export-if-defined=_emscripten_thread_crashed --export-if-defined=_emscripten_tls_init --export-if-defined=pthread_self --export-if-defined=__get_exception_message --export-if-defined=__cpp_exception --export-if-defined=__cxa_increment_exception_refcount --export-if-defined=__cxa_decrement_exception_refcount --export-if-defined=__thrown_object_from_unwind_exception --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=fflush --export=emscripten_stack_get_end --export=emscripten_stack_get_free --export=emscripten_stack_get_base --export=emscripten_stack_init --export=__cxa_demangle --export=stackSave --export=stackRestore --export=stackAlloc --export=__wasm_call_ctors --export=__errno_location --export=emscripten_dispatch_to_thread_ --export=_emscripten_thread_free_data --export=emscripten_main_browser_thread_id --export=emscripten_main_thread_process_queued_calls --export=emscripten_run_in_main_runtime_thread_js --export=emscripten_stack_set_limits --export=malloc --export=free --export=__cxa_is_pointer_type --export=__cxa_can_catch --export=setThrew --export=__trap --export=emscripten_webgl_make_context_current --export=emscripten_webgl_get_current_context --export=saveSetjmp --export=ntohs --export=htons --export=__dl_seterr --export=htonl --export=emscripten_builtin_memalign --export-table -z stack-size=5242880 --initial-memory=65536000 --no-entry --max-memory=65536000 --global-base=1024' failed (returned 1)
[build] ninja: build stopped: subcommand failed.
[build] Build finished with exit code 1

Any idea what i am doing wrong and get this missing export errors?

My version:

➜  dev git:(ngsp-wasm) ✗ emcc --version
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.15 (8b4443a87f5eab5dbb9adb690f9ebed0a9da4bd9)
Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

BTW: The reason why I want to switch to WASM EH in the first place, is that i hope to see some actual stack traces, when i get a CPP exception. This would make debugging much easier. But this already discussed here: #17437 and here #17466

[sbc100]

Can you try removing both -sDISABLE_EXCEPTION_THROWING=0 and -sNO_DISABLE_EXCEPTION_CATCHING .. i believe those options are only relevant when targeting emscripten exceptions.

[aheejin]

I acknowledge that there is not enough documentations on how Wasm EH and SjLj work together. I'm planning on improving that too.

But in the meantime, to explain the status quo, there are two EH methods (Emscripten (old) and Wasm (new)), and also there are two SjLj methods (Emscripten (old) and Wasm (new)). The Emscripten EH/SjLj use JavaScript to do emulate things. They've been around longer so they are more stable, but they are slow and they increase code size more. Wasm EH/SjLj uses the new Wasm EH proposal. This has not been standardized yet. This needs browser support, but most major browsers already support it, including V8, Firefox, and Safari. I regard Wasm EH stable enough to be tried in bigger applications at this point. Wasm SjLj is little more experimental; even though it uses the same browser support, the toolchain support has been around for shorter amount of time than that of Wasm EH. But you can certainly try.

And there are restrictions depending on which combinations you want to use.

• Emscripten EH + Emscripten SjLj: Works fine. No restrictions. Slow. Stable.
• Emscripten EH + Wasm SjLj: We don't support this.
• Wasm EH + Emscripten SjLj: We support this as an interim measure, but there is a restriction that you can't use setjmp call with exceptions within the same function. This is what you encounter here. Even though you don't use try-catch in that function, stack-allocated objects can create landingpads, so this can happen. You can modify source code to work around it but if it is third party code as in you case that might not be easy.
• Wasm EH + Wasm SjLj: What we eventually want to recommend to everyone when things are stable enough. But you can try. You can add -sSUPPORT_LONGJMP=wasm to both compile and link time flags. This combination has a restriction too but a less bothering one: You can't call setjmp within catch clause in try-catch.

[major-mayer]

Thanks for your very informative answer, now a lot of things make much more sense to me.
I now compile my code with -fwasm-exceptions and -sSUPPORT_LONGJMP=wasm and et voila, no link errors :)
Let's see if this experimental WASM SjLj feature generates some other errors on runtime.

Still I have another problem, because when i build with -gsource-map or -g, the link step need incredible amounts of memory (40GB+) and eventually crashes with SIGKILL or SIGSEGV, but that's for another issue....

[sbc100]

What process is it that is taking all the memory? Is it wasm-ld, wasm-opt or something else?

[major-mayer]

wasm-emscripten-finalize, but i opened a seperate issue for this problem a few seconds ago: #17538

[major-mayer]

Now that it finally runs, I am completely blown away how much faster my module runs with WASM EH enabled.
This is not just 2x faster, but an order of magnitudes.
I am not sure if that's because of WASM EH or also because of other flags that I now enabled, but nevertheless really amazing to see. Great work