summaryrefslogtreecommitdiff
path: root/include/bridges
AgeCommit message (Collapse)AuthorFilesLines
2024-09-18.NET Bindings: Native bridge for .NETRMZeroFour2-0/+117
This patch includes all marshalling and proxy handling code on the .NET side as well as the native side needed for a fully functional UNO bridge. It also includes some changes and corrections to net_basetypes and netmaker needed for the bridge to work properly. It also includes the FirstUnoContact example in C# as demonstration. Change-Id: I406932938a4415d24408fb41ddfa7d8eeb5d1f94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170916 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2024-07-10Properly implement cppu::throwException for EmscriptenStephan Bergmann1-1/+2
...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>
2024-06-21Embind: Fix C++ UNO exception catchingStephan Bergmann1-0/+107
...with a new Module.catchUnoException JS function that can be used in a JS catch block to provide the thrown UNO exception as an Any. (For a non-C++ exception, it rethrows the exception, and for a non-UNO C++ exception it maps it to css.uno.RuntimeException.) The implementation reuses parts of bridges/source/cpp_uno/gcc3_wasm/, which have been moved to a new StaticLibrary_emscriptencxxabi. Change-Id: I708fe6121c43a1b9736de5dff449f6c4f32a45f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169325 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>