...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>
...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>
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
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Relevant announcement from revision history for NDK 23 [1]:
> * GNU binutils, excluding the GNU Assembler (GAS), has been removed. GAS
> will be removed in the next release. If you are building with
> -fno-integrated-as, file bugs if anything is preventing you from
> removing that flag.
Therefore, switch from uses of GNU binutils to the
corresponding LLVM tools instead.
NDK 20.x doesn't provide `llvm-ranlib` yet, so bump the minimum
version to 21.x.
Also drop the previous uses of `ANDROID_BINUTILS_PREBUILT_ROOT`,
which appear to no longer be relevant by now.
commit 4082a18406
Date: Wed Nov 22 23:08:06 2017 +0100
android: use unified headers and llvm-c++ STL (x86) with NDK 16
gnustl (and others) are to be removed in future versions of the ndk
also bump gradle and build-tools to current versions along with it
arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix
that later
that introduced one of those uses mentions issues on ARM, but building
and running the app at least on my 32-bit ARM device (Samsung Galaxy S4 I9505,
LineageOS 17.1/Android 10) didn't show any issues in a quick test
with this change in place.
Update the Jenkins config to switch from the now no longer
supported NDK 20.1.5948944 to 23.2.8568313 for which building and
running the app has been tested on devices for all of the four
supported architectures with upcoming change
Change-Id I9ea714255faf29d50bb5f8e206f13495637da867
"android: Require NDK 23 and use default linker lld" in place
on top, s. that one's commit message for more details.
Note however that the NDK version will be further updated to use
NDK 25 in upcoming change
Change-Id Ib8e65f433ee89ff1bc12432722570bf8f9f7ed85
("android: Support NDK 24.x and 25.x, use NDK 25 for Jenkins").
[1] https://developer.android.com/ndk/downloads/revision_history
[2] https://lists.freedesktop.org/archives/libreoffice/2023-January/089878.html
Change-Id: I7645f8025d42f0fa384b5bceb31bb4b1c0a44cb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146118
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementations at bridges/source/cpp_uno/gcc3_solaris_intel and
bridges/source/cpp_uno/gcc3_solaris_sparc are apparently dead and should thus be
removed. Those were the only bridge implementations for Solaris, but the
referenced thread mentions that there are recent builds for OpenIndiana x86-64
(however they are done; presumably using
bridges/source/cpp_uno/gcc3_linux_x86-64), so keep general support for Solaris
intact for now.
Change-Id: I09ec098f5509f25a126342536745509bbe9faaac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146059
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_linux_s390 is
apparently dead and should thus be removed. However, that was the only bridge
implementation for 32-bit S390, which implies that support for the 32-bit S390
architecture as a whole is dead and should thus be removed.
Change-Id: I18b3b4fa11df4ce693107bad6bbea2fab1c19f26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Some failed test are caused by the bridges when testing on the
loongarch64 machine. After adjust the function parameters and return
value processing according to the characteristics of the loongarch64
architercture. I tested in version 7.4.3 on the loongarch64 machine, and
all tests passed.
Change-Id: I9c67287cd7cc89fd79a907afdbffa507bb6052e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144986
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
1. Configure gbuild
2. Add UNO Bridge for riscv64
Till now base function works well on riscv64. The bridgetest has passed.
Test on Debian, Gentoo and openEuler.
Credits:
- Heiher <r@hev.cc> and Stephan Bergmann <sbergman@redhat.com>
The riscv64 bridge implementation refers to mips64 and
AArch64 bridges.
- Bo Yu <tsu.yubo@gmail.com> configures gbuild for riscv64.
- WANG Xuerui <xen0n@gentoo.org> provides lots of guiding tips.
Change-Id: Ifad3b0de8b2c9e7328627ed03396bbd45a9c71e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137445
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
as that what it actually is and the compiler defines are already
-DMIPS/-DMIPS64 anyway (as are the PLATFORMID and the bridges'
name mips/mips64)
Change-Id: I274e7a3b0e140375a8e697c1790cbdb972251d29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137489
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: René Engelhard <rene@debian.org>
... and use the same fake exception rethrowing code then the
mobile platforms.
Change-Id: Ic90de1cfd1e0092d6064d041a613d60d9f5f76b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128596
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
How did that even pass in Jenkins on Android Arm?
Regression from commit c859b4aa48
("gbuild: introduce gb_%_linktarget_target").
Change-Id: Id06cc151e92e221da856814d69eb8cced167b427
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127829
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This introduces two concepts: a plugin and its loader (library)
LO currrently has dependency cycles for some libraries. There is
scui, which depends on sc, while sc dlopen's scui. There are the
various vclplug_*, i18npool plugins, filters/gie, acc, etc.
Usually these plugins link to their loader library, because they
use its symbols. But as a result there is no sensible way to
express the runtime dependency of loaders on the plugins.
In GNU libtool plugins are called modules and they are implemented
in an IMHO more sensible way by allowing missing symbols at link
time. This way you can have a dependency from the loader library
to its plugins, as the plugins don't depend on the loader, but you
lose the link time detection of missing symbols.
While this is in theory possible in LO too, LO currently has
plugins, like acc (accessibility), loaded by tk (toolkit), which
depends on svt (svtools), which itself depends on tk, so dropping
the tk dependency for acc on its own doesn't help :-(
And while the dependency of the plugins on their loader is fine
for the shared / DYNLOADING build, for the "static" builds you
must (somehow) link the plugins into the executables.
I also codeified a few rules into the build system along with it:
* just plugins are allowed to depend / link other plugins
* plugins aren't allowed to be linked into the merge lib
* plugin loaders are "limited" to libraries
At the high level, this is implemented via new gbuild calls:
* gb_Library_set_plugin_for,lib,loader: declare a library to be a
plugin of a loader library and add a dependeny from the plugin
library to the loader library
* gb_Library_set_plugin_for_nodep,lib,loader: ^^^^ without adding
the library dependeny
* gb_Helper_register_plugins_for_install: "plugin" replacement for
gb_Helper_register_libraries_for_install to implement some
additional checks in the build system
In the end this patch just adds a bit syntactic sugar and nothing
changes for any build.
Change-Id: I7b01d9c384cbc5838bd2cc93aff18e4868939d6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126163
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
I was wondering why removing instdir stuff forced a rebuild of
the cross toolset. Turned out some cross-toolset bits were wrongly
depending on host build stuff. It even had FIXME...
As a consequence, gb_CPPU_ENV was replaced by config_host.mk flags
to provide an CPPU_ENV_FOR_BUILD and also uses the correct
OS_FOR_BUILD.
Change-Id: I50e8e8dca50ab1ad3164948a585a792a52e4a39a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116359
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The Windows platform is called Arm64. But now that the ID for Mac
is also going to be renamed from arm64 to aarch64, this get's rid
of the arm64 as the UNO identifier and user in gbuild, just like
on all other Arm64 platforms.
Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Since Microsoft follows the general ARM64 ABI calling conventions,
and the SEH exception handling is the same, this result is a mixed
port of the gcc3_linux_aarch64 bridge and the refactored x86-64
exception handling.
I have no idea, if the complicated 32-bit handling in RaiseInfo()
is needed, as the ARM64 trampolines definitly use 64-bit code.
But since this is the first working version, I currently don't
mind much ;-)
There is definitly more potential for refactoring in the whole
bridges directory...
Change-Id: I9782a2e99c0231cdd1286af156ad312229eccf39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103642
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This is almost just refactoring, but with classes like type_info_
and __type_info, just following the code became tendious. I tried
to come up with better names... and in the end included some minor
code changes described below.
This patch moves the "common" code for MSVC exception handling
into msvc_shared/except.cxx. Still it contains a few small ifdefs,
so it doesn't feel like clean separation, but a lot of duplicate
code is dropped this way.
The "major" code change for amd64 is the drop of the duplicate
static RTTInfo object originally used by mscx_getRTTI and
mscx_getRTTI_len, by merging of both functions into the single,
new get() function to use a single std::find call.
Change-Id: Ib07d40e2794cde79156be3324c80ccf21a6aa8ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102864
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
At least when building the libreoffice rpm on Fedora 33, the relevant -flto...
flags are passed in via the global CFLAGS/CXXFLAGS, and no --enable-lto
configure option is given. That caused this library to be built with LTO there,
which in turn caused at least aarch64 to fail the %check step with
> ### unexpected exception content! failed
> ### unexpected exception content! failed
> ### unexpected exception content! failed
> exception test failed
> oneway exception test failed
> exception occurred: error: test failed! testtools/source/bridgetest/bridgetest.cxx:1176
>
> > error: error: test failed! testtools/source/bridgetest/bridgetest.cxx:1176
> > dying...make[1]: *** [testtools/CustomTarget_uno_test.mk:25: workdir/CustomTarget/testtools/uno_test.done] Error 1
> make: *** [Makefile:166: CustomTarget_testtools/uno_test] Error 2
The easiest fix appears to pass -fno-lto unconditionally: For one, both GCC and
Clang appear to support it since before our baseline versions (GCC: baseline
7.0.0, presumably supported since <https://gcc.gnu.org/git/?p=gcc.git;a=commit;
h=d7f09764d7bc66b9997c811c22e11efc87b44792> "Merge lto branch into trunk" in
releases/gcc-4.5; Clang: baseline 5.0.2 (at least on Linux), presumably
supported since <https://github.com/llvm/llvm-project/commit/
10d0868efb320fc33ced13b0abeea7070cd41635> "Driver: Support -fno-lto" in
releases/3.0.x). For another, the other (few) places in the code that check
ENABLE_LTO appear not to be relevant at least for that Fedora 33 rpm build, so
there appears to be no incentive to make that build configure --enable-lto as an
alternative to this fix.
Change-Id: I4735403660e57ef73b99d6a8cc5945c6d8e2af73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101129
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
At least with Clang 12 trunk on Linux, CustomTarget_testtools/uno_test aborted
with
libc++abi: terminating with uncaught exception of type com::sun::star::uno::RuntimeException
at
> #0 0x0000ffffad97e598 in raise () from /lib64/libc.so.6
> #1 0x0000ffffad96ada0 in abort () from /lib64/libc.so.6
> #2 0x0000ffffadbf704c in abort_message (format=format@entry=0xffffadbfa398 "terminating with %s exception of type %s") at /llvm/llvm-project/libcxxabi/src/abort_message.cpp:78
> #3 0x0000ffffadbe50ec in demangling_terminate_handler () at /llvm/llvm-project/libcxxabi/src/cxa_default_handlers.cpp:67
> #4 0x0000ffffadbf633c in std::__terminate (func=<optimized out>) at /llvm/llvm-project/libcxxabi/src/cxa_handlers.cpp:59
> #5 0x0000ffffadbf92ac in __cxxabiv1::failed_throw (exception_header=0x361b5970) at /llvm/llvm-project/libcxxabi/src/cxa_exception.cpp:152
> #6 __cxxabiv1::__cxa_throw (thrown_object=0x361b59f0, tinfo=0x43f5a0 <typeinfo for com::sun::star::uno::RuntimeException>, dest=0xffffa0575b84 <com::sun::star::uno::RuntimeException::~RuntimeException()>) at /llvm/llvm-project/libcxxabi/src/cxa_exception.cpp:283
> #7 0x0000ffffa056944c in bridge_object::(anonymous namespace)::Test_Impl::getRaiseAttr1 (this=0x361810c0) at testtools/source/bridgetest/cppobj.cxx:296
> #8 0x0000ffffa0644b70 in callVirtualFunction (function=281473371790408, gpr=0xffffcc4c1b68, fpr=0xffffcc4c1b28, stack=0xffffcc4c18d0, sp=0, ret=0xffffcc4c1cf0) at bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:38
> #9 0x0000ffffa064c5b4 in (anonymous namespace)::call (proxy=0x36193710, slot=..., returnType=0x3615b380, count=0, parameters=0x0, returnValue=0xffffcc4c1cf0, arguments=0xffffcc4c1cf0, exception=0xffffcc4c1e78) at bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:176
> #10 0x0000ffffa064bd58 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch (pUnoI=0x36193710, pMemberDescr=0x361a5b70, pReturn=0xffffcc4c1cf0, pArgs=0xffffcc4c1cf0, ppException=0xffffcc4c1e78) at bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:328
> #11 0x0000ffffa064b174 in (anonymous namespace)::call (proxy=0x361a9280, description=..., returnType=0x3615b380, count=0, parameters=0x0, gpr=0xffffcc4c2070, fpr=0xffffcc4c20b0, stack=0xffffcc4c20f0, indirectRet=0x361a92a8) at bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:120
> #12 0x0000ffffa064a900 in vtableCall (functionIndex=37, vtableOffset=0, gpr=0xffffcc4c2070, fpr=0xffffcc4c20b0, stack=0xffffcc4c20f0, indirectRet=0x361a92a8) at bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:240
> #13 0x0000ffffa065c1cc in vtableSlotCall () from instdir/program/libgcc3_uno.so
> #14 0x0000ffffa05f9ce0 in bridge_test::performTest (xContext=uno::Reference to (cppu::(anonymous namespace)::ComponentContext *) 0x3616eac0, xLBT=uno::Reference to (com::sun::star::uno::XInterface *) 0x361a92a8, noCurrentContext=false) at testtools/source/bridgetest/bridgetest.cxx:527
> #15 0x0000ffffa05f7400 in bridge_test::(anonymous namespace)::TestBridgeImpl::run (this=0x361806e0, rArgs=uno::Sequence of length 1 = {...}) at testtools/source/bridgetest/bridgetest.cxx:1168
> #16 0x00000000004050c0 in sal_main () at cpputools/source/unoexe/unoexe.cxx:517
> #17 0x00000000004040cc in main (argc=8, argv=0xffffcc4c4458) at cpputools/source/unoexe/unoexe.cxx:357
The reason is that _Unwind_RaiseException (in libgcc_s.so.1) called from
__cxa_throw (in libc++abi.so.1) for some reason does not find unwind information
for the callVirtualFunction frame #8, so returns _URC_FATAL_PHASE2_ERROR. This
looks similar to the issue discussed in the comment at the top of
bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx introduced with
0fdbb5b0ea "Make cpp_uno/gcc3_linux_x86-64 bridge
work with GCC 4.7". Though what happens to fix it here appears to be
-fasynchronous-unwind-tables. (The -fnon-call-exceptions mentioned in that
comment appears to be ignored by Clang.)
The actual difference that -fasynchronous-unwind-tables makes in the generated
callvirtualfunction.s is that it drops a single line
> .Lfunc_begin0:
> .file 7 "" "bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx"
> .loc 7 32 0 // bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:32:0
> - .cfi_sections .debug_frame
> .cfi_startproc
> // %bb.0:
> stp d15, d14, [sp, #-128]! // 16-byte Folded Spill
Change-Id: Ib60e9f4958c6041b10ca959a0953e998ac6f141a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100614
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Use the same code as for Linux on aarch64, with minor
additional hacks. But that will not actually work in all cases, as
there are slight differences in the ABI. See
https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
Thus we can drop the use of the lo_mobile_throwException() hack that
was very temporarily used.
The run-time code generation requires use of a new API on macOS to
work: See the use of pthread_jit_write_protect_np() in
bridges/source/cpp_uno/shared/vtablefactory.cxx.
For some reason, with the Xcode 12 betas, when compiling for
arm64-apple-macos, the symbols for the type_infos for the UNO
exception types (_ZTIN3com3sun4star3uno16RuntimeExceptionE etc) end up
as "weak private external" in the object file, as displayed by "nm -f
darwin". We try to look them up with dlsym(), but that then fails. So
use a gross hack: Introduce separate real variables that point to
these typeinfos, and look up and dereference them instead. If this
hack ends up needing to be permanent, instead of having a manually
edited set of such pointer variables, we should teach codemaker to
generate corresponding functions, and look up and invoke them to get
the std::type_info pointer.
When compiling for x86_64-apple-macos, the type_info symbols end up as
"weak external" which is fine.
With this, LibreOffice starts and seems to work to some extent, and
many unit tests succeed.
Change-Id: I05f46a122a51ade1ac7dccd57cb90e594547740e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100408
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
...redux, after 8473ac2e27 "Elide use of
rtl_Instance (which is obsoleted by C++11 thread-safe statics)" had done the
same in parallel but forgot to remove some now-unnecessary parts:
There appears to be no good reason to control the lifecycle of the VtableFactory
instance via dso_init/exit, instead of via a plain static local variable.
This removes the need for the Windows DllMain functions. They also called
DisableThreadLibraryCalls, which disables the DLL_THREAD_ATTACH and
DLL_THREAD_DETACH notifications for the respective DllMain. Lets assume that
this was only done (as an optimization) because there had to be a user-provided
DllMain, and that it was not in itself a reason to have a user-provided DllMain.
(Most other DllMain across the code base that call DisableThreadLibraryCalls
also do something else. The only DllMain that only calls
DisableThreadLibraryCalls is the one in
shell/source/win32/shlxthandler/ooofilt/ooofilt.cxx, introduced with
3fbfb21e29 "INTEGRATION: CWS desktintgr02".)
Change-Id: I696e1c8d49060853c1a2c24f67469f6adfea6801
Reviewed-on: https://gerrit.libreoffice.org/85367
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
At least when doing an aarch64 Flatpak build against org.freedesktop.Sdk//19.08,
which uses GCC 9.2.0 and passes in `CXXFLAGS=-O2 -g -pipe
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables
-fstack-clash-protection`, callVirtualMethod (in
bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx) would
decrement the stack pointer another 16 bytes after the
stackargs = alloca(...);
and before the asm block, so in the called virtual function, arguments read from
the stack would read garbage (and CustomTarget_testtools/uno_test would fail
with SIGSEGV at
> #0 0x0000ffffb733eb48 in rtl::OUString::operator= (this=0xaaaaf9c1ac30, str=...) at /run/build/libreoffice/include/rtl/ustring.hxx:453
> #1 0x0000ffffb733a7bc in bridge_object::assign (rData=..., bBool=true, cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:99
> #2 0x0000ffffb733a87c in bridge_object::assign (rData=..., bBool=true, cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=..., rSequence=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:115
> #3 0x0000ffffb733ade4 in bridge_object::Test_Impl::setValues (this=0xaaaaf9c1abb0, bBool=1 '\001', cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=..., rSequence=..., rStruct=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:548
> #4 0x0000ffffb740bff4 in callVirtualFunction (function=281473755360772, gpr=0xffffd1ab1f28, fpr=0xffffd1ab1f68, stack=0xffffd1ab1d40, sp=8, ret=0xffffd1ab22c0) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:63
> #5 0x0000ffffb740ca70 in (anonymous namespace)::call (proxy=0xaaaaf9c291c0, slot=..., returnType=0xaaaaf9c00770, count=17, parameters=0xaaaaf9c3a210, returnValue=0xffffd1ab22c0, arguments=0xffffd1ab2230, exception=0xffffd1ab2370) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:178
> #6 0x0000ffffb740d4c4 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch (pUnoI=0xaaaaf9c291c0, pMemberDescr=0xaaaaf9c55950, pReturn=0xffffd1ab22c0, pArgs=0xffffd1ab2230, ppException=0xffffd1ab2370) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:361
> #7 0x0000ffffb740720c in (anonymous namespace)::call (proxy=0xaaaaf9c549c0, description=..., returnType=0xaaaaf9c00770, count=17, parameters=0xaaaaf9c3a210, gpr=0xffffd1ab2510, fpr=0xffffd1ab2550, stack=0xffffd1ab2590, indirectRet=0xffffb7d24790) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:120
> #8 0x0000ffffb74079a0 in (anonymous namespace)::vtableCall (functionIndex=40, vtableOffset=0, gpr=0xffffd1ab2510, fpr=0xffffd1ab2550, stack=0xffffd1ab2590, indirectRet=0xffffb7d24790) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:291
> #9 0x0000ffffb7407b00 in (anonymous namespace)::vtableSlotCall (gpr0=187651311618536, gpr1=1, gpr2=64, gpr3=17, gpr4=4660, gpr5=65244, gpr6=305419896, gpr7=4275878552, fpr0=5.4321266044931319e-315, fpr1=3.1415926358999999, fpr2=0, fpr3=4.0039072046065485, fpr4=0, fpr5=4.003911019303815, fpr6=8.9589789687541617e+102, fpr7=-4.4588500238274385e-308) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:348
> #10 0x0000ffffb739e60c in bridge_test::performTest (xContext=..., xLBT=..., noCurrentContext=false) at /run/build/libreoffice/testtools/source/bridgetest/bridgetest.cxx:378
> #11 0x0000ffffb73a3d58 in bridge_test::TestBridgeImpl::run (this=0xaaaaf9c18550, rArgs=...) at /run/build/libreoffice/testtools/source/bridgetest/bridgetest.cxx:1162
> #12 0x0000aaaad292a3ec in sal_main () at /run/build/libreoffice/cpputools/source/unoexe/unoexe.cxx:509
> #13 0x0000aaaad29297a0 in main (argc=8, argv=0xffffd1ab31b8) at /run/build/libreoffice/cpputools/source/unoexe/unoexe.cxx:349
.)
By experiment, I found the problematic thing to be -fstack-clash-protection,
which can apparently be cancelled with a subsequent -fno-stack-clash-protection
at least on that GCC 9.2.0. (And -f[no-]stack-clash-protection appears to only
be available since GCC 8, and not at all for Clang, so check for it with
HAVE_GCC_STACK_CLASH_PROTECTION.)
Change-Id: If667fdf704b1ba20a04593b38d2d1f079280df41
Reviewed-on: https://gerrit.libreoffice.org/80701
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
E.g. gb_LinkTarget_add_exception_object adds it explicitly, but
gb_LinkTarget_add_cxxobject itself does not, even though other variants
(c,objc,objcxx) do it.
This means that when compiling tools/qa/cppunit/test_cpuid.cxx it
doesn't get the correct -O/-g flags, because CppunitTest_tools_test.mk
uses gb_CppunitTest_add_cxxobjects to add $(INTRINSICS_CXXFLAGS).
And that in its own actually should use the add_exception_objects variant,
it didn't presumably because that one used to have cxxflags passing broken
until I fixed it in 4bbdab901e. The usage
in Library_cpp_uno.mk even explicitly works around the lack of debug symbols.
Change-Id: Idc794e95bb817cd2ba2942b8e1f04f80d6722f97
Reviewed-on: https://gerrit.libreoffice.org/80119
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
support for targeting API 14 and 15 was removed in NDK 18, so set
minimum version to 16
mips support was removed in NDK 17
Clang now takes care about correct linking with libc++ shared or
static, so don't manually specify them anymore.
Same with __ANDROID_API_LEVEL__ define and the sysroot / isystem
handling, that is all covered by a single -target <triple><version>
simplifying things quite a bit.
also align ownloud sdk values with main build.gradle
Change-Id: Ib3ae4484e52214677e826270b731ecf7c5c15445
Reviewed-on: https://gerrit.libreoffice.org/77104
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
This gets rid of the horrible hack in gbuild.mk to accomodate the
case-incorrect iOS platform makefiles that cannot be renamed without
upsetting git on file systems that sadly lack the case sensitivity
feature.
Keep the macro defined to IOS though.
Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234
Reviewed-on: https://gerrit.libreoffice.org/62705
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
The perl script just generated static asm code, this
code is now included directly in ios64_helper.s
Change-Id: I3ebc6f85865287e1a1d11f82be72fc2407bcb40f
the simulator is a normal MAC compile, with different SDK
so the cpp_uno bindings should be identical
Change-Id: Ie53463beab628414185b492c78dcb3d8364794bf
Refer to the mac code, instead of copying it to gcc3_ios, when
running in simulator.
There is a problem with the macro calls, so the reference to the sources
are duplicated.
Change-Id: I72848ba960b8a7f85708723bfeb682ceecc1e448
gnustl (and others) are to be removed in future versions of the ndk
also bump gradle and build-tools to current versions along with it
arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix
that later
Change-Id: Ic794c3293b599b77ec48096bf3283a99c09cbb79
Reviewed-on: https://gerrit.libreoffice.org/45163
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
8d12e4ec8b "No -fstack-protect-strong for
gcc3_linux_aarch64/cpp2uno.cxx vtableSlotCall" had done that in the past (so
that setting up the x0/x1 return registers in vtableSlotCall is not clobbered
by the stack protector code), but gbuild details have apparently changed in the
meantime, so that gb_CXXFLAGS_COMMON's -fstack-protector-strong now ends up on
the compiler command line before what is covered by gb_Library_add_cxxobjects's
argument, so didn't get subst'ed to -fstack-protector. That caused Flathub
aarch64 builds to fail in CustomTarget_testtools/uno_test.
However, if both -fstack-protector-strong and -fstack-protector are present on
the command line, the second apparently wins, so use that hack for now.
(-fstack-protector-strong is only available since GCC 4.9, but -fstack-protector
is already available in our current baseline GCC 4.8.1, and even for a build on
that baseline it wouldn't hurt if cpp2uno.cxx was explicitly built with
-fstack-protector even if none of the other files were built with
-fstack-protector-strong.)
Change-Id: I9d78d2e5b08b7c0a4adb1531b482cd43617886f7
When compiling for the simulator it is like compiling
for macosx (64bit) but with other libraries, therefore
the bridge should be like the macosx.
Change-Id: I59f1442a5c77d09ad0bc4bf31c2432fc32ef725e
Changed __i386 to not __arm64
iOS either compiles for arm64 (production) or x86_64 (simulator)
add common parts to cpp2uno and uno2cpp
Change-Id: I059f3cc23bb658d6d53dbf2bf4aa6634eeac9662
Supporting 32bit iOS, means a.o. adding several libraries to
the dependency list because macOSX does not install them by
default (e.g. zlib).
32bit is only used in old iPhones.
updated configure.ac
removed from solenv/gbuild/platform
bridges corrected
Change-Id: I415e744a9cb4acb3b5fbfca33c22940a1d56e390
Stephan Bergmann