| Age | Commit message (Collapse) | Author |
|---|
|
Loongarch is a new RISC ISA , which includes a 32-bit version and a 64-bit version, Here are some documents about Loongarch：
https://github.com/loongson/LoongArch-Documentation.
The loongarch64 bridges implementation refers to mips64 bridges, and the code related to abi and asm has been modified
Change-Id: I1d9cd3aadf63046c8cdecc9a64842567bfa1cecc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137486
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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 c859b4aa48956cbf5ff41280b0008456e8f5189c
("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>
|
|
Just some refactoring.
Change-Id: I47adb93f8a413d289f6abb2a48ed3f049f582a46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127799
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>
|
|
Change-Id: I614fb662b164b0af9ca03c3ab8006b9105380112
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102865
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
0fdbb5b0eabbaa571f3747fda12a56c938cba474 "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>
|
|
From http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD .
This time, do not apply the add-on change from
25a09c8776cc6088a5b2bf13dc84eb386c26bb7e to config.sub, but keep it
pristine. Instead, let's start using the name "aarch64" instead of
"arm64" for macOS and iOS in the autofoo context, as that is what
those tools call it. Clang and Apple call it arm64, though.
Change-Id: I1e05866c5fb08e0800cdfeaf7f6a71bfb43d1777
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100272
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
* For one, as discussed in the comment at <https://gerrit.libreoffice.org/c/
core/+/91978/2#message-97da6c6ece7ae7bd49e9eb4843be333192fcc057> "Port to
FreeBSD aarch64":
"So it looks like Clang does not treat those register asm as we expect it would,
at least on aarch64.
"Witness a local Linux recent master --with-distro=LibreOfficeAndroidAarch64
[i.e., using Clang] build's
> $ llvm-objdump --disassemble instdir/program/libgcc3_uno.a
[...]
> 0000000000000000 <vtableSlotCall>:
> 0: ff 43 03 d1 sub sp, sp, #208
> 4: f4 4f 0b a9 stp x20, x19, [sp, #176]
> 8: fd 7b 0c a9 stp x29, x30, [sp, #192]
> c: fd 03 03 91 add x29, sp, #192
> 10: a8 43 00 91 add x8, x29, #16
> 14: bf 83 1d f8 stur xzr, [x29, #-40]
> 18: e0 07 04 a9 stp x0, x1, [sp, #64]
> 1c: e2 0f 05 a9 stp x2, x3, [sp, #80]
> 20: e4 17 06 a9 stp x4, x5, [sp, #96]
> 24: e6 1f 07 a9 stp x6, x7, [sp, #112]
> 28: e0 07 00 6d stp d0, d1, [sp]
> 2c: e2 0f 01 6d stp d2, d3, [sp, #16]
> 30: e4 17 02 6d stp d4, d5, [sp, #32]
> 34: e6 1f 03 6d stp d6, d7, [sp, #48]
> 38: a8 03 1c f8 stur x8, [x29, #-64]
> 3c: a0 43 5e b8 ldur w0, [x29, #-28]
> 40: a1 03 5e b8 ldur w1, [x29, #-32]
> 44: a5 83 5e f8 ldur x5, [x29, #-24]
> 48: e4 03 08 aa mov x4, x8
> 4c: e2 03 01 91 add x2, sp, #64
> 50: e3 03 00 91 mov x3, sp
> 54: f3 03 01 91 add x19, sp, #64
> 58: f4 03 00 91 mov x20, sp
> 5c: 00 00 00 94 bl 0x5c <vtableSlotCall+0x5c>
> 60: 60 06 40 a9 ldp x0, x1, [x19]
> 64: 80 06 40 6d ldp d0, d1, [x20]
> 68: 82 0e 41 6d ldp d2, d3, [x20, #16]
> 6c: fd 7b 4c a9 ldp x29, x30, [sp, #192]
> 70: f4 4f 4b a9 ldp x20, x19, [sp, #176]
> 74: ff 43 03 91 add sp, sp, #208
> 78: c0 03 5f d6 ret
[...]
vs. [this commit's vtableslotcall.s; see below for details].
"And also latest Clang 12 trunk still does e.g.
> $ cat test.c
> void f(long);
> void g() {
> register long volatile a asm ("x8");
> f(a);
> }
> $ clang --target=unknown-linux-aarch64 -S -O2 test.c
> $ cat test.s
> .text
> .file "test.c"
> .globl g // -- Begin function g
> .p2align 2
> .type g,@function
> g: // @g
> // %bb.0: // %entry
> sub sp, sp, #16 // =16
> ldr x0, [sp, #8]
> add sp, sp, #16 // =16
> b f
> .Lfunc_end0:
> .size g, .Lfunc_end0-g
> // -- End function
> .ident "clang version 12.0.0 (git@github.com:llvm/llvm-project eb31ddd71eb44d53ebe12a09c9587198bb6f2a2e)"
> .section ".note.GNU-stack","",@progbits
> .addrsig
"(This is probably also the underlying issue that
eb15ac837e06087fb8148330e9171d6697d89ee6 'android: Avoid throwing exceptions
through the bridges' tries to hack arond.)"
* For another, this also gets rid of the
dddb527db1562f30a2a2b20338dfc8458086a4a9 "Again, no -fstack-protector-strong for
gcc3_linux_aarch64/cpp2uno.cxx" hack.
The contents of the new vtableslotcall.s is effectively the GCC 10 -S output of
the old vtableSlotCall C++ function from cpp2uno.cxx. (And as cpp2uno.cxx only
takes the address of vtableSlotCall, never calls it directly, it does not matter
that it declares it with an imprecise
extern "C" void vtableSlotCall();
signature.)
Change-Id: Icfbf0622a47825ff7cf21008de27d3da6a2f0ebd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99660
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...redux, after 8473ac2e27efff3ec902a358896a669ce05f047a "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
3fbfb21e298ba506c50733d4aaefc7550bca2fe4 "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 4bbdab901eb3c7d32d28910fb830f4b0422eee91. 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>
|
|
Change-Id: Id8aae84308f6128351ae2f93c8fbc8941a0c7fc6
Reviewed-on: https://gerrit.libreoffice.org/79085
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.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>
|
|
...after eeeec33ada5923f1f534334b22c15d6e2c6f1d35 "merge
--enable-selective-debuginfo into --enable-symbols" had removed it
Change-Id: I83aed6e21c4b983d8645707daa65bd85ec16ff6b
Reviewed-on: https://gerrit.libreoffice.org/71798
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.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
|
|
Change-Id: I9e699eea04231eeeff4146657124ee4f0e68412d
|
|
Change-Id: I219d556f8e124cfe426cc1ac3c54da34eb7ef790
Reviewed-on: https://gerrit.libreoffice.org/49925
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I285838f6f3e8ec57a63239f71a403809154c47e2
|
|
Change-Id: Ie9f3aa8057e9b50beedf47ff892188cf3b362194
|
|
Still comparing the "old" gcc3_ios_arm with the new one, in order to make
the asm code work.
Change-Id: I3a2fdfc1891a6a4d7065917f5ef8bd19c49b3987
|
|
Change-Id: Iad8cfd72803864bd1c8a5d01c74e1f856c27685d
|
|
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>
|
|
8d12e4ec8b843d59661a12a7a92bfec7e4473e0f "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
|
|
Need to adapt for other iOS CPU´s
Change-Id: Icb0b49265d3ec67057e57bfe5610389afe404568
|
|
cppu_no_leak and bndchk were remnants from pre-gbuild times
Change-Id: Ie9f325c20e39c100b4a7180a9925559f58bcca6b
Reviewed-on: https://gerrit.libreoffice.org/34153
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8ec9bb5415a9e6b9083ba89a7790872d67625de1
|
|
Change-Id: I523bc1d848e40489370eefe00046e0a257ed2505
Reviewed-on: https://gerrit.libreoffice.org/27058
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
.. accessibility, avmedia, basctl, basic and bridges
remove boost from module if not needed anymore
Change-Id: I6177f8276766a0a7df1703e81bf1b448912df6e2
Reviewed-on: https://gerrit.libreoffice.org/23744
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1fcf3afadefcd5af472523fd8fca123fb3ab4095
|
|
...in anticipation of building with clang-cl.exe on Windows
Change-Id: I1d723c9d3b5ca8a2bc6b27ef0189a7b053581398
Reviewed-on: https://gerrit.libreoffice.org/19928
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Since df62a2c81bef2bcd96a5f14802e41815f0bdc2da gb_DEBUG_CFLAGS
was passed to bridge_noopt_objects target for MSVC to track
down EH breakage on 64 bit architecture. It was erroneously
done unconditionally. Fix it to only pass when one of:
--enable-dbgutil
--enable-debug
--enable-symbols
is present.
Change-Id: I2728c30156541be418c88a0ea284c0c6a16abba5
Reviewed-on: https://gerrit.libreoffice.org/19744
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
(i.e., if any of --enable-dbgutil, --enable-debug, or --enable-symbols);
introduce gb_DEBUGINFO_FLAGS for the platform-specific flags
Change-Id: I4306fa30ced57d40d5b1206a0b26a886411118ef
|
|
Change-Id: I71fd2f7d8bfd1b1511dec91f23b61b9f55d21472
Reviewed-on: https://gerrit.libreoffice.org/16845
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...similarly to 0fdbb5b0eabbaa571f3747fda12a56c938cba474 "Make
cpp_uno/gcc3_linux_x86-64 bridge work with GCC 4.7"
Change-Id: Idcafcb07678d02446172d7fde30631a342f6437e
|
|
Change-Id: Id949718baf77bb7e2d276d3db08f68149c114796
Reviewed-on: https://gerrit.libreoffice.org/13364
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
