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>
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
/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
...that ae6ee262d7 "Some fixing of
msvc_win32_arm64 UNO bridge" had removed, assuming it wasn't actually necessary.
But looks like Windows exception handling stack unwinding somehow needs it after
all. Getting past the CustomTarget_testtools/uno_test getRaiseAttr1() call now
(but still failing at some later place).
Change-Id: I1e84345f2f355ab1e480c779da6b221b744132b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166616
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
For one, the Windows ABI deviates from the generic aarch64 ABI regarding
returning class instances by value from non-static member functions, see
<https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#return-values>:
"The caller shall reserve a block of memory of sufficient size and alignment to
hold the result. The address of the memory block shall be passed as an
additional argument to the function in x0, or x1 if $this is passed in x0. The
callee may modify the result memory block at any point during the execution of
the subroutine. The callee returns the address of the memory block in x0."
That means RETURN_KIND_HFA_FLOAT and RETURN_KIND_HFA_DOUBLE are not needed, and
can be cleaned up in a follow-up commit.
And for another, setting up a call stack frame in call() in uno2cpp.cxx for
callVirtualFunction() didn't actually work, so go with a slightly less ambitious
aproach (as also used by the gcc_linux_aarch64 bridge) and explicitly copy the
arguments that end up on the stack around in callVirtualFunction().
This allows CustomTarget_testtools/uno_test to proceed at least as far as the
call of getRaiseAttr1(), which still leads to an uncaught
css::uno::RuntimeException.
Change-Id: I4a8ec09c270864ac4de246d7e8d1f923198236b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166585
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
since
commit f93ae0455c
Date: Sat Feb 3 18:03:45 2024 +0100
Check bridges with IWYU
presumably not using the _LIBCPPABI_VERSION branch
move the _GLIBCXX_CDTOR_CALLABI fallback define to where
its used while I'm at it, that too seems to be from cxxabi.h
Change-Id: I2ead7207e3bcf24d3b120d22ae7f80e8f0a3216a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163672
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Andrea Gelmini