An Android build including autogen options
--with-android-ndk=$HOME/Android/Sdk/ndk/29.0.14206865
--with-distro=LibreOfficeAndroidAarch64
failed like this:
.../bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:604:29: error: cannot initialize a parameter of type 'char *' with an rvalue of type 'unsigned char *'
604 | __builtin___clear_cache(const_cast<unsigned char *>(begin), const_cast<unsigned char *>(end));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Tweak the version check introduced in
commit 28e542dc61
Date: Wed Apr 23 13:17:21 2025 +0200
Avoid loplugin:redundantcast on macOS with recent LLVM 21 trunk
...including
<https://github.com/llvm/llvm-project/commit/b6b025797245a5e5416b522df041252e3c4ff868>
"Fix the signature for __builtin___clear_cache (#134376)", which now caused
> bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:601:9: error: redundant reinterpret_cast, result is implicitly cast to void pointer [loplugin:redundantcast]
> 601 | reinterpret_cast<char *>(const_cast<unsigned char *>(begin)),
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:602:9: error: redundant reinterpret_cast, result is implicitly cast to void pointer [loplugin:redundantcast]
> 602 | reinterpret_cast<char *>(const_cast<unsigned char *>(end)));
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
to not expect the new signature for Android NDK <= 29,
for which __clang_major__ is 21, but which doesn't have the
relevant commit mentioned in the commit message quoted above.
The NDK 29 release notes mention [1]:
> Updated LLVM to clang-r563880c. See clang_source_info.md in the toolchain
> directory for version information.
~/Android/Sdk/ndk/29.0.14206865/toolchains/llvm/prebuilt/linux-x86_64/clang_source_info.md
contains this:
> Base revision: [386af4a5c64ab75eaee2448dc38f2e34a40bfed0](https://github.com/llvm/llvm-project/commits/386af4a5c64ab75eaee2448dc38f2e34a40bfed0)
That referenced llvm-projects commit
386af4a5c64ab75eaee2448dc38f2e34a40bfed0 is indeed before
the b6b025797245a5e5416b522df041252e3c4ff868 one mentioned
above.
[1] https://github.com/android/ndk/wiki/Changelog-r29
Change-Id: I88419d0d8d47563d6d0d236dc17806979e56c831
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192378
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It seems that both marshal_data and unmarshal_data are expected to
take only non-null argument. Further, the checks were corrected:
e.g., rtl_uString_release itself only takes a non-null argument,
so *ppUnoStr must be checked before the call, not ppUnoStr. The
static analyzer saw that ppUnoStr was checked if it was non-null;
and was dereferenced later, outside of the check, unconditionally.
The analyzer flagged that as a potential nullptr dereference. It
was a useful warning, flagging the actual code problem.
Unfortunately, our analyzer build in CI doesn't build DOTNET; I
found this locally.
Change-Id: I4bcbcd1ce8246835901c6032cae9e8b41a76dbf1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191060
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
malloc indeed can return a nullptr; we treat OOM situation as an
unrecoverable error; so add some asserts.
Change-Id: I937991248372d12e1688a046c9f67363312ac570
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191013
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
posix_fallocate() may be available but unimplemented for a
given filesystem. Detect that situation once and use ftruncate()
instead.
Change-Id: Ic1422bfbcbcda21ef4923a6fc30ceb5ce662db3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183977
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
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>
/uno2cpp.cxx: In function ‘void {anonymous}::callVirtualMethod(void*, sal_Int32, void*, typelib_TypeDescriptionReference*, sal_uInt32*, sal_uInt32, sal_uInt32*, sal_uInt32, double*)’:
/<<PKGBUILDDIR>>/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:278:5: error: ‘asm’ operand has impossible constraints or there are not enough registers
278 | __asm__ __volatile__ (
| ^~~~~~~
make[2]: *** [/<<PKGBUILDDIR>>/solenv/gbuild/LinkTarget.mk:338: /<<PKGBUILDDIR>>/workdir/CxxObject/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.o] Error 1
Just removing them makes it work, they are mentioned before anyway, too
(thanks Caolan)
Change-Id: Ibb9118b268a587ebdcfce343e2ee2605ac979915
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171650
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
...after 875997c896 "Properly implement
cppu::throwException for Emscripten" had implemented only those parts that were
absolutely necessary for that exception throwing. As detailed in the commit
message there, wasmcallgen has been extended to additionally generate all the
required vtable slot call trampoline code (which cannot be generated on the fly
for Wasm, as would be done for other platforms). Consequently, some of the
"callvirtualfunction"-centric file names have been changed to "generated" as the
output of wasmcallgen is now more general. (And wasmcallgen itself should also
be renamed, in a follow-up commit. And when adding to the wasmcallgen code
here, some existing parts of its implementation have been cleaned up, too.)
There is no direct way to test this half of the Wasm UNO bridge directly from
unotest/source/embindtest/embindtest.js, so a new
org.libreoffice.embindtest.BridgeTest singleton has been added, which triggers
new test code in unotest/source/embindtest/embindtest.cxx that tests the bridge
in a way similar to testtools' bridgetest machinery.
Change-Id: I521a1d6c2160aedc814f7603b0b99861e5fbd1eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170374
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...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
f4ec967599 "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>
...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>
<https://github.com/emscripten-core/emscripten/>
system/lib/libcxxabi/src/cxa_exception.h has two different definitions of that
struct, a short one for when __USING_EMSCRIPTEN_EXCEPTIONS__ is defined, and a
long one for the other case. In 7175431a4b
"Implement exception catching", I had naively copied the short version, assuming
that __USING_EMSCRIPTEN_EXCEPTIONS__ was something that sounded like it would be
defined with --enable-wasm-exceptions. But some debugging of actual exception
handling now showed that the assumption had apparently been wrong (though I
still have no idea about the semantics of that __USING_EMSCRIPTEN_EXCEPTIONS__
define, and when it would or would not be defined), and that I had copied the
wrong version.
The relevant test code
> try {
> const ret = invoke.invoke('throwRuntimeException', params, outparamindex, outparam);
> console.assert(false);
> ret.delete();
> } catch (e) {
> const [type, message] = getExceptionMessage(e);
> console.assert(type === 'com::sun::star::reflection::InvocationTargetException');
> console.assert(message === undefined); //TODO
> //TODO: inspect wrapped css.uno.RuntimeException
> decrementExceptionRefcount(e);
> }
in unotest/source/embindtest/embindtest.js had apparently happened to not cause a
crash with the wrong version of __cxxabiv1::__cxa_exception, but had also
happened to not detect the mistake due to the relevant parts being commented out
with TODO (because, in turn, proper UNO exception catching is still lacking in
our Embind-based JS binding).
Change-Id: I718087c7ed2c17808696267ece17237d5cdf2f54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169305
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
There appears to be no good reason that cpp2uno.cxx and uno2cpp.cxx are noopt
(presumably that was just cargo-culted from another platform?), and except.cxx
appears to be completely unused anyway.
Change-Id: Ic5f4142308a56b798dad61e9ec589046cad2ae13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168182
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
(Without 22ce8ed05b "Emscripten: Unconditional
--enable-wasm-exceptions", this would have failed to link due to missing
__cxa_current_exception_type and __cxa_get_globals.)
Change-Id: If89a3c62e4d2ac24d68f867b2fd7a4cd813d5a39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168176
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...by making the general UNO -> C++ function call case work (modulo handling
exceptions, which I'll look into later).
Wasm call_indirect unfortunately needs to statically know the call target's
signature, so we statically need to know all possible signatures. So introduce
wasmcallgen helper to scan the existing UNOIDL API upfront and generate the
relevant callvirtualfunction-wrapper.cxx and callvirtualfunction-inst.s code.
(The good thing is that the number of different signatures is somewhat limited,
each parameter can only be one of i32, i64, f32, or f64. So even if 3rd-party
extensions bring along new UNOIDL interface methods, chances are relatively high
that the signatures needed for them would already be covered by the existing
ones.)
Testing this can nicely be done in unotest/source/embindtest/embindtest.js via
css.script.Invocation (which internally exercises the relevant code). (Instead
of adding individual org.libreoffice.embindtest.StructLong/String etc., it would
be nicer to introduce some polymorphic StructOne<T>, but the Emind UNO binding
does not support polymorphic structs, so the embindtest.js code would not work.)
Change-Id: If829c9e3772bfd27561f3ad743d38a71d11545b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167308
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Andrea Gelmini