Properly implement cppu::throwException for Emscripten

...by implementing (for now) just enough of the cpp2uno half of the Wasm UNO
bridge to make it work.  In general, that half suffers from the same issue as
the already-implemented uno2cpp half, namely that Wasm doesn't allow to generate
code on the fly (which, in this case, would be needed to implement the vtable
slot trampoline functions).  So, for now just hard-code the few
vtableSlotFunction_* that are needed by the UNO interfaces for
cppuhelper/source/exc_thrower.cxx.  (A proper fix would probably use the same
approach as for the uno2cpp half, and use something like wasmcallgen to generate
at least all the vtableSlotFunction_* needed for udkapi/offapi upfront.)

The RTTI for the exceptions needs to be unique across the executable for
exception catching to actually work (as it compares exception types by RTTI
address rather than by name).  We thus need to export all the relevant RTTI
symbols (which I hacked into the existing wasmcallgen for now, even if that
makes that executable's name a slight misnomer now), and access them with a new
jsGetExportedSymbol.  (This exporting would also be needed by the "classical"
approach of using dlsym on the main module, cf.
<https://gerrit.libreoffice.org/c/core/+/167187> "WIP: Emscripten: Set up
support for dlsym from main module".  And while that dlsym approach would work,
it is much simpler to just use that jsGetExportedSymbol than to use a dlsym
detour, and thereby avoid all the hassle of -sMAIN_MODULE detailed in the commit
message of that Gerrit change.)

It also turned out that including Emscripten's <cxxabi.h> needs
__USING_WASM_EXCEPTIONS__ to be defined, because it uses that in its declaration
of __cxa_throw.  (The source for setting that define internally in Emscripten is
get_cflags in the emsdk's upstream/emscripten/tools/system_libs.py, which
defines __USING_EMSCRIPTEN_EXCEPTIONS__ for the non-Wasm, Emscripten JS
exception mode, and defines __USING_WASM_EXCEPTIONS__ for
--enable-wasm-exceptions, which we use.  The commit message of
f4ec967599f5dafa1ce477631d7c2e8de005e28f "Fix redefinion of Emscripten
__cxxabiv1::__cxa_exception" documents my prior confusion of when one or the
other would be defined.)

Change-Id: Id08765ab5b4ce1553dc3a61648324526185cb64c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170246
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>

1 files changed, 2 insertions, 1 deletions

diff --git a/include/bridges/emscriptencxxabi/cxxabi.hxx b/include/bridges/emscriptencxxabi/cxxabi.hxx
index 8c380961cb60..eda61f1229e4 100644
--- a/include/bridges/emscriptencxxabi/cxxabi.hxx
+++ b/include/bridges/emscriptencxxabi/cxxabi.hxx
@@ -16,6 +16,7 @@
 #include <exception>
 #include <typeinfo>
 
+#define __USING_WASM_EXCEPTIONS__
 #include <cxxabi.h>
 
 #include <config_cxxabi.h>
@@ -67,7 +68,7 @@ struct __cxa_exception
 #endif
     //  Manage the exception object itself.
     std::type_info* exceptionType;
-#if 1 //MODIFIED: #ifdef __USING_WASM_EXCEPTIONS__
+#ifdef __USING_WASM_EXCEPTIONS__
     // In wasm, destructors return their argument
     void*(/*MODIFIED: _LIBCXXABI_DTOR_FUNC*/ *exceptionDestructor)(void*);
 #else