summaryrefslogtreecommitdiff
path: root/bridges
AgeCommit message (Collapse)AuthorFilesLines
2020-09-17WIN bridges: unify cpp2uno common codeJan-Marek Glogowski5-618/+390
Change-Id: I614fb662b164b0af9ca03c3ab8006b9105380112 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102865 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-17WIN bridges: unify exception handlingJan-Marek Glogowski12-1012/+628
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>
2020-09-17WIN bridges: unify bridge code layoutJan-Marek Glogowski6-580/+547
This just a cosmetic change to minimize the diff between the files of the different msvc bridges, by renaming variables, adapting comments and reordering variables. This includes the reduction of the "using namespace" to com::sun::star, so a few types now gain an uno:: prefix. Change-Id: I2189d2ba223ed3fb51cfa94639c6ca03d26a83e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102863 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-04tdf#124176 Use #pragma once in bridgesGeorge Bateman46-165/+46
This commit was carried out by a Python script, source of which is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97. Change-Id: Icadf43a74e4ba99e587a1e6287adf8d65f819ca1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100144 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-21Pass -fno-lto unconditionallyStephan Bergmann1-1/+1
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>
2020-08-18Fix typosAndrea Gelmini1-1/+1
Change-Id: I9d55e4478d8cf3047b4ccac88e06fdc87e68e6ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100871 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-08-13gcc3_linux_{aarch64,x86-64} need the __cxa_exception hack in deleteExceptionStephan Bergmann2-8/+88
* gcc3_linux_aarch64 needs a hack to detect the reserve member in LLVM >= 10 libcxxabi __cxa_exception, in addition to the existing hack for LLVM 5. On macOS arm64 (which shares the bridges/source/cpp_uno/gcc3_linux_aarch64/ code) we know that we always target a >= LLVM 10 libcxxabi, so we do not need neither of the two hacks there. (And a7d1fed24557b203acb5016a98af26f4ef24d27a "Hack to dynamically adapt to __cxa_exceptiom in LLVM 5.0 libcxxabi" had introduced a "fillUnoException" vs. "mapException" typo in the comment when it copied it from bridges/source/cpp_uno/gcc3_macosx_x86-64/except.cxx.) * Similarly, gcc3_linux_x86_64 needs both hacks when it is built against libcxxabi (and the need for the LLVM 5 hack had gone unnoticed there for now). * It is not clear to me now why gcc3_macosx_x86-64 needs the LLVM 5 hack (which I even initially developed for that platform, 7a9dd3d482deeeb3ed1d50074e56adbd3f928296 "Hack to dynamically adapt to __cxa_exceptiom in LLVM 5.0 libcxxabi") but not the LLVM >= 10 hack (although it does need the corresponding hack in fillUnoException when running against recent upstream LLVM trunk libcxxabi, f4b6f6a8ae60bdec53512728d00853b73fa18500 "Hack to dynamically adapt to __cxa_exceptiom in LLVM 11 libcxxabi". Change-Id: I8e7a5c871fbeeaf82bbd16fa03e73f10f229da93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100656 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-13Document that the deleteException hack is only relevant for LLVM 5, not laterStephan Bergmann3-14/+16
Change-Id: I2d93d3d76f2fe5e24e6864725184519c0595076b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100638 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-13gcc3_linux_aarch64 also needs the hack to dynamically adapt to __cxa_exceptionStephan Bergmann2-2/+42
...in LLVM 10 libcxxabi, same as f4b6f6a8ae60bdec53512728d00853b73fa18500 "Hack to dynamically adapt to __cxa_exceptiom in LLVM 11 libcxxabi" for gcc3_macosx_x86-64 and 986bd28388df745dd969e7be7c3bda36b2b2cb0e "ofz#24641 libc++abi __cxa_exception has grown another member" for gcc3_linux_x86-64. (Note that 91c8a3f3e7d3c178952d7e78e24cd0d6ba2b165a "The __cxa_exception::reserve member has been backported to LLVM 10 libcxxabi" found out that this is already relevant for LLVM 10, contrary to the mentioned commits' subject lines.) On macOS arm64 (which shares the bridges/source/cpp_uno/gcc3_linux_aarch64/ code) we know that we always target a >= LLVM 10 libcxxabi, so we do not need the hack there. Change-Id: I49e3d5b06b0b427ee3edeb10281025e4b9f2615f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100644 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-12Let exceptions pass through aarch64 callVirtualFunction built with ClangStephan Bergmann1-0/+1
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>
2020-08-12The __cxa_exception::reserve member has been backported to LLVM 10 libcxxabiStephan Bergmann5-12/+12
...so record that fact in our comments, to avoid confusion Change-Id: I83a9c576a92d74c207c8c778df0d020daf5bf33d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100593 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-10Make the C++/UNO bridge work to some extent on macOS on arm64Tor Lillqvist7-9/+106
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>
2020-08-07Update config.{guess,sub} with latest versions and handle fallout of thatTor Lillqvist1-5/+8
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>
2020-08-06ofz#24641 libc++abi __cxa_exception has grown another memberCaolán McNamara2-0/+42
https: //github.com/llvm/llvm-project/commit/f2a436058fcbc11291e73badb44e243f61046183 this is the same problem as commit f4b6f6a8ae60bdec53512728d00853b73fa18500 Author: Stephan Bergmann <sbergman@redhat.com> Date: Thu Feb 13 08:40:11 2020 +0100 Hack to dynamically adapt to __cxa_exceptiom in LLVM 11 libcxxabi (where the new change to __cxa_exception effectively reverts the change that prompted 7a9dd3d482deeeb3ed1d50074e56adbd3f928296 "Hack to dynamically adapt to __cxa_exceptiom in LLVM 5.0 libcxxabi") Change-Id: Iec4ef1dc188bea2223d99b1b7eb8adec636c98e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88583 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> so c-n-p that solution here Change-Id: I4475757a766e3ade7b9fcaf6149e535c9f9a4fa4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100209 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-29Replace brittle gcc3_linux_aarch64 vtableSlotCall with pure assembler codeStephan Bergmann3-65/+75
* 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>
2020-05-08compact namespace in avmedia..bridgesNoel Grandin28-62/+60
Change-Id: Iba1282caadab91a0c6e1c044dbab5e6e15f3707b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93705 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-06Move all public Java classes to libreoffice.jarSamuel Mehrbrodt1-4/+2
This moves the classes from juh.jar and ridl.jar to libreoffice.jar The goal is to have one single jar (and Java module, will be added later) which developers can include to work with LO. juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar on its classpath to keep backwards compatibility. This is a continuation of ae855bf48163ff64d94cfc34aff8e37abdb5518d and a preparation to have Java 9 module support. Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-30Use a less extreme entitlement for our run-time machine code generationTor Lillqvist1-0/+6
See https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-executable-page-protection and https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-jit Change-Id: I192038efa9cff4fb723bf4bdc8644f0b09f0fcda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93181 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-04-18loplugin:flatten in bridgesNoel Grandin4-208/+208
Change-Id: I736032df48cb491508c27cbe773b964d1d2359b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92482 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-14loplugin:buriedassign in b*Noel Grandin1-1/+2
Change-Id: Ic20f46105a30b54bc5a991b4070e6c8edb15376e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92189 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-26Extend loplugin:cstylecast to certain function-style castsStephan Bergmann1-1/+1
...that are equivalent to const_cast or reinterpret_cast, and should arguably better be written that way for clarity. Drawing inspiration from <https://reviews.llvm.org/D76572> "Replace `T(x)` with `reinterpret_cast<T>(x)` everywhere it means reinterpret_cast. No functional change". Change-Id: I27b8f70d324d32ecba658db4d1c2db03e10d5d3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91086 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-23.eh_frame section should probably have type @unwindStephan Bergmann1-1/+1
(i.e., SHT_X86_64_UNWIND) rather than @progbits (i.e., SHT_PROGBITS). Discussion at <https://groups.google.com/forum/#!topic/x86-64-abi/uVATLOU5PQA> "SHT_X86_64_UNWIND" sounds like both @unwind and @progbits are used in practice, but Clang/LLVM now started to fail with > /home/sbergman/lo/core/bridges/source/cpp_uno/gcc3_linux_x86-64/call.s:79:2: error: changed section type for .eh_frame, expected: 0x70000001 > .section .eh_frame,"a",@progbits > ^ after <https://github.com/llvm/llvm-project/commit/ 75af9da755721123e62b45cd0bc0c5e688a9722a> "[MC][ELF] Error for sh_type, sh_flags or sh_entsize change". Change-Id: I07cae987f7449c526a7130beee7a71d01afc457e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89305 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-13Hack to dynamically adapt to __cxa_exceptiom in LLVM 11 libcxxabiStephan Bergmann2-1/+46
(where the new change to __cxa_exception effectively reverts the change that prompted 7a9dd3d482deeeb3ed1d50074e56adbd3f928296 "Hack to dynamically adapt to __cxa_exceptiom in LLVM 5.0 libcxxabi") Change-Id: Iec4ef1dc188bea2223d99b1b7eb8adec636c98e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88583 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-12Blind fix for Linux aarch64 with libcxxabiStephan Bergmann1-2/+2
...after untested a7d1fed24557b203acb5016a98af26f4ef24d27a "Hack to dynamically adapt to __cxa_exceptiom in LLVM 5.0 libcxxabi" had been submitted Change-Id: I68694645825ddebb249a90d9af9b8ba04c0bdbb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88519 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-12Hack to dynamically adapt to __cxa_exceptiom in LLVM 5.0 libcxxabiStephan Bergmann1-0/+22
...for Linux aarch64, similar to 7a9dd3d482deeeb3ed1d50074e56adbd3f928296 "Hack to dynamically adapt to __cxa_exceptiom in LLVM 5.0 libcxxabi" for macOS x86-64. But unlike on macOS (which is known to always use libcxxabi), be careful to only execute the hack in builds targeting libcxxabi. Change-Id: I5417fde425d2d6bac9400592193a9fe5d2bfe175 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88458 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-26remove some unused local varsNoel Grandin1-1/+0
found by a more aggressive variant of loplugin:unusedvariables. This is my first pass, committing the simplest and most obviously unnecessary vars Change-Id: I9676a6e39a101937097788548764506c93811c57 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87414 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-14clang-tidy modernize-concat-nested-namespace in basic..canvasNoel Grandin6-12/+12
Change-Id: I74a575e6ca7829ee252c0e315fc337ea223c944f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86758 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-07aarch64 r18 is reserved at least on AndroidStephan Bergmann1-2/+5
<https://github.com/ARM-software/software-standards/blob/master/abi/aapcs64/ aapcs64.rst> states: "The role of register r18 is platform specific. If a platform ABI has need of a dedicated general purpose register to carry inter- procedural state (for example, the thread context) then it should use this register for that purpose. If the platform ABI has no such requirements, then it should use r18 as an additional temporary register." For a --host=aarch64-linux-android build, Clang warned > bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:39:9: error: inline asm clobber list contains reserved registers: X18 [-Werror,-Winline-asm] > "ldp x0, x1, [%[gpr_]]\n\t" > ^ > <inline asm>:1:1: note: instantiated into assembly here > ldp x0, x1, [x20] > ^ > bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:39:9: note: Reserved registers on the clobber list may not be preserved across the asm statement, and clobbering them may lead to undefined behaviour. > "ldp x0, x1, [%[gpr_]]\n\t" > ^ > <inline asm>:1:1: note: instantiated into assembly here > ldp x0, x1, [x20] > ^ and <https://github.com/llvm/llvm-project/commit/ 9c9c8b22d2ea150cc889232871b0c8303d3644d9> "Start reserving x18 by default on Android targets" shows that at least LLVM/Clang claims that the Android ABI reserves it (though it doesn't cite any sources for that). (If this bridges/source/cpp_uno/ implementation is used for other non-Linux OS like Fuchsia, we may need to extend the #if accordingly; see the above LLVM commit for which platforms it claims reserve the register.) Change-Id: I62a5210ddc4784eee2ab56ee134b9e195827b9dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86366 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18Silence -Werror,-WuninitializedStephan Bergmann1-0/+1
...as seen with "Android (5220042 based on r346389c) clang version 8.0.7 (https://android.googlesource.com/toolchain/clang b55f2d4ebfd35bf643d27dbca1bb228957008617) (https://android.googlesource.com/toolchain/llvm 3c393fe7a7e13b0fba4ac75a01aa683d7a5b11cd) (based on LLVM 8.0.7svn)", warning about functionIndex, vtableOffset, and indirectRet being used "uninitialized" (but which is as intended, carrying over the values those registers have upon entry to the function) Change-Id: I443fe2e8bf7c25a5bd2bfd99c245d430be65f445 Reviewed-on: https://gerrit.libreoffice.org/85400 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18tdf#128671: Rely on unwind.h, declare what's missing from cxxabi.hStephan Bergmann3-36/+92
...for gcc3_linux_aarch64, similar to what 128deeae81a6f802bfb79b8f0fa8c4b10729f7db "cxxabi.h is not specific to GCC" et al did for gcc3_linux_x86-64 Change-Id: Iee9980842c0e5f6f49642407339a67e865f8be9c Reviewed-on: https://gerrit.libreoffice.org/85344 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18Fix typos concerning the __cxa_exception checkStephan Bergmann2-2/+2
...introduced with 069506bcb0ee4005b01c22095ed427b96b553c98 "Use config_cxxabi.h to check for __cxa_eh_globals, __cxa_exception", but which appear to have been harmless as (a) the checked-for __cxxabiv1::__cxa_exceptions never existed in cxxabi.h, and (b) lack of __cxxabiv1::__cxa_exception in cxxabi.h happened to conincide with !HAVE_CXXABI_H_CXA_EH_GLOBALS Change-Id: I13f8a2b3cf0f03f2bc96cf053d2b571860055978 Reviewed-on: https://gerrit.libreoffice.org/85373 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18Elide use of rtl_Instance (which is obsoleted by C++11 thread-safe statics),Stephan Bergmann5-122/+4
...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>
2019-12-18Elide use of rtl_Instance (which is obsoleted by C++11 thread-safe statics)Noel Grandin1-21/+1
which does not seem to have been doing anything useful here anyway, not since commit 730399de90add4e35da9754a8f7525b443237026 Date: Wed Jul 18 11:16:06 2007 +0000 INTEGRATION: CWS unomacli64 (1.6.50); FILE MERGED 2007/06/20 10:29:46 kr 1.6.50.1: fixed: #i78284# Change-Id: I57345a08c333953a66b3a5f3be1fe9a2f1f092ef Reviewed-on: https://gerrit.libreoffice.org/85328 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-10loplugin:unusedmember (clang-cl)Stephan Bergmann1-1/+1
(The struct that is the type of EHExceptionRecord::params does not need a name.) Change-Id: I372630563dce26c3ac190a9492eabfad9a55a943 Reviewed-on: https://gerrit.libreoffice.org/84861 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-06loplugin:external (macOS)Stephan Bergmann2-0/+8
* OldEntry in fpicker/source/aqua/resourceprovider.mm was apparently unused ever since it got introduced with 00657aef09d854c74fb426a935a3e8b1fc390bb0 "migrate to boost::gettext" * impl_throwError is used from multiple TU, connectivity/source/drivers/macab/MacabStatement.cxx just missed the relevant #include Change-Id: Iba131da57aa20085bb1c634ba9a3a59566070abd Reviewed-on: https://gerrit.libreoffice.org/84653 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-05loplugin:external (clang-cl)Stephan Bergmann1-1/+18
...plus loplugin:consttobool and loplugin:fakebool fallout Change-Id: Ie3d8121815c080b13bea6d9deca1eb138ca56138 Reviewed-on: https://gerrit.libreoffice.org/84515 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-05android: Avoid throwing exceptions through the bridges.Jan Holesovsky1-0/+4
From some reason it does not work, so let's do the same we are doing on iOS; at least for now. Change-Id: I915f8683a112548fc3defc1114f9dce3aa7be30e Reviewed-on: https://gerrit.libreoffice.org/84067 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/84204 Tested-by: Jenkins Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2019-12-02bridges arm64: Use [[falltrough]].Jan Holesovsky3-9/+9
Change-Id: I28d3cabab74bea6ea9f2712c240110a44643c54d Reviewed-on: https://gerrit.libreoffice.org/84193 Tested-by: Jenkins Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann2-0/+6
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-19loplugin:fakebool (clang-cl)Stephan Bergmann1-1/+1
...plus follow-up loplugin:implicitboolconversion and loplugin:redundantcast Change-Id: I9fc9c5cb46fbb50da87ff80af64cb0dfda3e5f90 Reviewed-on: https://gerrit.libreoffice.org/83207 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-17Extend loplugin:external to warn about enumsStephan Bergmann1-0/+4
To mitigate the dangers of silently breaking ADL when moving enums into unnamed namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79 "New loplugin:external"), note all functions that are affected. (The plan is to extend loplugin:external further to also warn about classes and class templates, and the code to identify affected functions already takes that into account, so some parts of that code are not actually relevant for enums.) But it appears that none of the functions that are actually affected by the changes in this commit relied on being found through ADL, so no adaptions were necessary for them. (clang::DeclContext::collectAllContexts is non-const, which recursively means that External's Visit... functions must take non-const Decl*. Which required compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support such Visit... functions with non-const Decl* parameters.) Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd Reviewed-on: https://gerrit.libreoffice.org/83001 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-06loplugin:indentation find broken if statementsNoel Grandin1-1/+1
so I don't read the "then" block as being a sequential statements Change-Id: Ib2004acd3518bd4ebd2246f02a26c2c0a8bbab4c Reviewed-on: https://gerrit.libreoffice.org/82069 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-05typeinfo fix for x86Tomoyuki Kubota1-1/+1
Change-Id: Ic0a9dcb97cfda4155f33d9ad07a96db8960b57a0 Reviewed-on: https://gerrit.libreoffice.org/82023 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-17Remove some memset callsMike Kaganski2-2/+1
Replace them with default initialization or calloc Change-Id: I747f53c2ced2d0473fd5a5ede4f8520a0633dcc1 Reviewed-on: https://gerrit.libreoffice.org/80805 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-16loplugin:bufferadd loosen some constraintsNoel Grandin1-10/+2
and extend O*StringView to have a constructor that takes a pointer and a length Change-Id: I6120e96280f030757e855a6596efdae438b7e1e8 Reviewed-on: https://gerrit.libreoffice.org/80872 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-12aarch64 callVirtualFunction needs to be compiled w/o -fstack-clash-protectionStephan Bergmann1-1/+6
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>
2019-10-04always use gb_LinkTarget__get_cxxflags for cxxobjectsLuboš Luňák1-11/+8
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>
2019-09-24latest update of Visual Studio complains about typeinfo.hTomoyuki Kubota1-1/+1
Change-Id: If8643ddd823ec1c970a7211be1547853162659a0 Reviewed-on: https://gerrit.libreoffice.org/79461 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-23android: add support for 64bit buildChristian Lohmaier2-1/+11
Change-Id: Id8aae84308f6128351ae2f93c8fbc8941a0c7fc6 Reviewed-on: https://gerrit.libreoffice.org/79085 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2019-09-19improve and enable loplugin:fragiledestructorNoel Grandin1-1/+1
Where the problem was benign and the class was not extended, I marked the class as final. Where the problem was benign and the class was extended, I marked the relevant callee methods as final. Other cases were excluded in the plugin. Change-Id: Idb762fb2206af4e8b534aa35ff77f8368c7909bc Reviewed-on: https://gerrit.libreoffice.org/79089 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-01 12:07:06 +0000