office-gobmx/bridges/CustomTarget_gcc3_wasm.mk

31 lines
1.2 KiB
Makefile
Raw Normal View History

# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t; fill-column: 100 -*-
#
# This file is part of the LibreOffice project.
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
#
$(eval $(call gb_CustomTarget_CustomTarget,bridges/gcc3_wasm))
$(eval $(call gb_CustomTarget_register_targets,bridges/gcc3_wasm, \
generated-cxx.cxx \
generated-asm.s \
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>
2024-07-09 10:28:46 -05:00
exports \
))
$(gb_CustomTarget_workdir)/bridges/gcc3_wasm/generated-asm.s \
$(gb_CustomTarget_workdir)/bridges/gcc3_wasm/generated-cxx.cxx \
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>
2024-07-09 10:28:46 -05:00
$(gb_CustomTarget_workdir)/bridges/gcc3_wasm/exports: \
$(call gb_Executable_get_target_for_build,wasmbridgegen) \
$(call gb_UnoApi_get_target,udkapi) \
$(call gb_UnoApi_get_target,offapi)
$(call gb_Executable_get_command,wasmbridgegen) \
$(gb_CustomTarget_workdir)/bridges/gcc3_wasm/generated-cxx.cxx \
$(gb_CustomTarget_workdir)/bridges/gcc3_wasm/generated-asm.s \
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>
2024-07-09 10:28:46 -05:00
$(gb_CustomTarget_workdir)/bridges/gcc3_wasm/exports \
+$(call gb_UnoApi_get_target,udkapi) +$(call gb_UnoApi_get_target,offapi)
# vim: set noet sw=4 ts=4: