summaryrefslogtreecommitdiff
path: root/bridges
AgeCommit message (Collapse)AuthorFilesLines
2021-05-07loplugin:noexcept (macOS)Stephan Bergmann3-9/+9
Change-Id: I7eede75da6b81777661e0e5b76c8877e122f941b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115224 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-05WASM: add initial support for Emscripten cross buildJan-Marek Glogowski1-0/+2
- configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-05-04loplugin:noexcept (macOS)Stephan Bergmann1-1/+1
Change-Id: Ib8951e9590d70ffecf8fd6af3070ef9c6d4ae151 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115044 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-02throw() -> noexcept, part 2/3: Automatic loplugin:noexcept rewriteStephan Bergmann2-8/+8
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-29loplugin:stringadd simplify some *StringBuffer operationsNoel Grandin1-12/+9
pulled from a larger patch which I created with a more permissive variant of this plugin Change-Id: I7abf1f3f09e84703b6e0e52fe9587dff691b2187 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114875 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein1-2/+4
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein1-0/+0
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-03-23Rename LO Windows arm64 ID to aarch64Jan-Marek Glogowski1-7/+6
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>
2021-03-02Handle floating-point return values correctly on iOSTor Lillqvist1-13/+11
The code did not work at all. The contents of register d0 that we tried to access in MapReturn() was not what the called function had stored there. Probably the clobber list in the __asm__ statement is wrong? Anyway, simpler to fix it by explicitly storing d0, too, into a variable after the call, like we do for x0 and x1, and then pass that variable, too, to MapReturn(). Fixes https://github.com/CollaboraOnline/online/issues/1519 . Change-Id: Id05c8c57209eb9ade4d67035830b2dec601bc046 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111826 Tested-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111835
2021-02-10Remove unneeded breaksAndrea Gelmini1-1/+0
Extending this: https://gerrit.libreoffice.org/c/core/+/110512 Change-Id: If7e6f9c4079c2e0b48e642aa0b140fb4e03996bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110520 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-09loplugin:stringview (clang-cl)Stephan Bergmann1-2/+2
Change-Id: I5c2420d5fb886926540bb3502c130404786f1698 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110641 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-02Fix some warnings for Raspberry pi 4 (part4)Julien Nabet3-55/+21
Fix similar pbs as previous commits Change-Id: Ib2964329f75402cd5457e4bf3362076c0d4f4ea2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108572 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-02Fix some warnings for Raspberry pi 4 (part3)Julien Nabet3-88/+117
fix for these kinds of things: /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:494:17: error: C-style cast from 'sal_uInt32 *' (aka 'unsigned long *') to 'double *' (BitCast) [loplugin:cstylecast] INSERT_DOUBLE( pCppArgs[nPos], nGPR, pGPR, pStack, pStackStart ); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:365:14: note: expanded from macro 'INSERT_DOUBLE' *(double *)pDS = *reinterpret_cast<double *>( pSV );\ ^~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:645:18: error: C-style cast from 'const typelib_TypeDescription *' (aka 'const _typelib_TypeDescription *') to 'typelib_InterfaceAttributeTypeDescription *' (aka '_typelib_InterfaceAttributeTypeDescription *') (BitCast) [loplugin:cstylecast] ((typelib_InterfaceAttributeTypeDescription *)pMemberDescr)->pAttributeTypeRef, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:655:31: error: use 'true' instead of 'sal_True' [loplugin:fakebool] aParam.bIn = sal_True; ^~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:656:31: error: use 'false' instead of 'sal_False' [loplugin:fakebool] aParam.bOut = sal_False; /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:112:47: error: NullToPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] typelib_TypeDescription * t = 0; ^ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:123:40: error: NullToPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] if (p->pBaseTypeDescription != 0) ^ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:148:52: error: NullToPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] typelib_TypeDescription * pTypeDescr = 0; ^ Change-Id: Ibca65077131277380ddeefa994b52c7c1193c1f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108570 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-02Fix some warnings for Raspberry pi 4 (part2)Julien Nabet2-18/+24
Fix these kinds: /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:103:10: error: externally available entity 'is_complex_struct' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] bool is_complex_struct(const typelib_TypeDescription * type) ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:129:10: error: externally available entity 'is_float_only_struct' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] bool is_float_only_struct(const typelib_TypeDescription * type) ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:168:6: error: externally available entity 'MapReturn' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] void MapReturn(sal_uInt32 r0, sal_uInt32 r1, typelib_TypeDescriptionReference * pReturnType, sal_uInt32* pRegisterReturn) /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:446:32: error: static_cast from 'void **' to 'sal_Int32 *' (aka 'long *') is not allowed sal_Int32 * pTempIndices = static_cast<sal_Int32 *>(pCppArgs + nParams); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ or some of these: In file included from /home/pi/lo/libreoffice/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c:26: /usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1945:1: error: unknown attribute 'externally_visible' ignored [-Werror,-Wunknown-attributes] _JNI_IMPORT_OR_EXPORT_ jint JNICALL ^ /usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1943:32: note: expanded from macro '_JNI_IMPORT_OR_EXPORT_' define _JNI_IMPORT_OR_EXPORT_ JNIIMPORT ^ /usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:35:42: note: expanded from macro 'JNIIMPORT' define JNIIMPORT __attribute__((externally_visible,visibility("default"))) Change-Id: I7cae1c52ee10306da666c9c234b9af7248efd04e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108567 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-01Add rtti.hxx for gcc3_linux_armJulien Nabet1-0/+33
Change-Id: I0fd541a320d3e27e45c29d59cd8bb08054042003 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108558 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-01Fix some warnings for Raspberry pi 4 (part1)Julien Nabet4-24/+25
/home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx:31:10: error: replace "..." include form with <...> for inclusion of a source file not next to the current source file, or a header, /home/pi/lo/libreoffice/bridges/inc/cppinterfaceproxy.hxx [loplugin:includeform] include "cppinterfaceproxy.hxx" ^~~~~~~~~~~~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:200:41: error: variable 'dret' is uninitialized when used here [-Werror,-Wuninitialized] *(double*)pRegisterReturn = dret; ^~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:199:33: note: initialize the variable 'dret' to silence this warning register double dret asm("d0"); ^ = 0.0 /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:191:40: error: variable 'fret' is uninitialized when used here [-Werror,-Wuninitialized] *(float*)pRegisterReturn = fret; ^~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:190:32: note: initialize the variable 'fret' to silence this warning register float fret asm("s0"); ^ = 0.0 make[1]: *** [/home/pi/lo/libreoffice/solenv/gbuild/LinkTarget.mk:301 : /home/pi/lo/libreoffice/workdir/CxxObject/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.o] Erreur 1 /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/except.cxx:66:22: error: parentheses immediately inside vardecl statement [loplugin:unnecessaryparen] long n = (*p++ - '0'); ^~~~~~~~~~~~ 1 error generated. make[1]: *** [/home/pi/lo/libreoffice/solenv/gbuild/LinkTarget.mk:301 : /home/pi/lo/libreoffice/workdir/CxxObject/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.o] Erreur 1 /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/except.cxx:66:22: error: parentheses immediately inside vardecl statement [loplugin:unnecessaryparen] long n = (*p++ - '0'); ^~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/except.cxx:88:11: error: externally available entity 'RTTI' is not previously declared in an included file (if it is only used in this translation unit, put it in an unnamed namespace; otherwise, provide a declaration of it in an included file) [loplugin:external] class RTTI ~~~~~~^~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/except.cxx:220:42: error: parentheses immediately inside vardecl statement [loplugin:unnecessaryparen] __cxa_exception const * header = ((__cxa_exception const *)pExc - 1); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/except.cxx:260:12: error: statement mis-aligned compared to neighbours [loplugin:indentation] ::uno_any_destruct( pUnoExc, 0 ); ^ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/except.cxx:246:13: note: measured against this one [loplugin:indentation] typelib_TypeDescription * pTypeDescr = 0; ^ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/except.cxx:262:12: error: statement mis-aligned compared to neighbours [loplugin:indentation] static RTTI rtti_data; ^ Change-Id: I054212e829c57b64b23612338b238d987bb17041 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108553 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-12-18Mention relevant Clang bug in commentStephan Bergmann1-1/+3
Change-Id: I88140ab20440125d9642a1489e501cdcb74c3a48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107962 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-17Various minor loplugin fixes (macOS ARM64)Stephan Bergmann4-79/+123
Change-Id: I32276e3ceafa1e65671ba395de3f6fa587179d79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107878 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-17Make the pthread_jit_write_protect_np call pair exception-safeStephan Bergmann1-38/+43
...just in case Change-Id: Id056ee4dfd64dd186f01d117cfede28f4b7f6c09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107867 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-16Fix macOS ARM64 RTTI generationStephan Bergmann1-54/+13
The Apple ARM64 ABI can use RTTI that is either unique (std::type_info equality is decided by comparing pointers to RTTI names) or non-unique (equality is decided by deep string comparison of RTTI names), where the most-significant bit of a std::type_info's name pointer must be set to indicate the non-unique case. See the " NonUniqueARMRTTIBit" comment at <https://github.com/llvm/llvm-project/ blob/be00e8893fdb814e67d8f06401afe869f878c4cf/libcxx/include/typeinfo#L143> for details. It appears that Clang, at least under -fvisibility=hidden as used by LO, emits RTTI for a C++ class as .private_extern and non-unique, even if the class is marked as visibility("default") (as is done for the C++ classes representing UNO exception types, cf. CPPU_GCC_DLLPUBLIC_EXPORT in include/cppu/macros.hxx). So it is expected and harmless that Rtti::getRtti will not find existing RTTI symbols via dlsym, and needs to create RTTI on the fly. However, what was missing was to set the most-significant bit of the name pointer, to indicate non-uniqueness. (My understanding is that things should even have worked whe we failed to set that bit, as comparison should fall back to deep string comparison if at least one of the involved RTTIs has the bit set, which the RTTI emitted by Clang does, see above. It looks like there is a bug though, see <http://lists.llvm.org/pipermail/libcxx-dev/2020-December/001060.html> "[libcxx-dev] Is the implementation of two-argument __non_unique_arm_rtti_bit_impl;;__is_type_name_unique correct?") Change-Id: I3c39edf569ac668352bbb73e60303856e1b63445 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107839 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-08tdf#134754: Gracefully handle EINVAL from mmap MAP_JIT on old macOSStephan Bergmann1-4/+15
Change-Id: Idfb148fad55c7c6b6e6f4f4b5316fd3b086f7d2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107365 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-06Related tdf#134754: Detect failed mmap on macOSStephan Bergmann1-0/+5
Change-Id: I21202d25e4851725198c58c29d9820bda00f2b30 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107315 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-13Improve the C++/UNO bridge for macOS on Apple SiliconTor Lillqvist2-2/+258
Now bridgetest (as improved by my previous commit) passes. That doesn't necessarily prove much, though, I am sure there are interesting corner cases that it doesn't exercise. Anyway, making this work was easier than I had feared. Unlike the arm64 ABI used on Linux, on macOS (and iOS, but we don't really use the C++/UNO bridge for iOS) we need to pack parameters smaller than eight bytes according to their natural alignment. Bytes take one byte, shorts two bytes aligned at a two-byte boundary, etc. Change-Id: I5b7dc2f8fce41ddec88df0e688898a074d8b2dad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105773 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-11-13tdf#123936 Formatting files in module bridges with clang-formatPhilipp Hofer4-73/+68
Change-Id: Ice8b5ff4ddde1b0eca19cf29c418e3281389926d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105648 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-10-14loplugin:external (clang-cl)Stephan Bergmann1-0/+5
Change-Id: I2d636f229ea52505cc263ea0219cf9f00130effd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104241 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-14loplugin:includeform (clang-cl)Stephan Bergmann1-4/+4
Change-Id: If1cffd3896d87695ba189728d8c1f1f04d55b6b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104242 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-14loplugin:stringconstant (clang-cl)Stephan Bergmann1-1/+1
Change-Id: I407b5e80a331950790f549ac8a50e8d7e49ee6d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104245 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-14loplugin:redundantcast (clang-cl)Stephan Bergmann2-3/+3
Change-Id: I2918d9ac8a4600bf5729604bda1beffb1dca78d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104244 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-14-Werror,-Wmicrosoft-exception-spec (clang-cl)Stephan Bergmann1-1/+1
> C:/lo/core/bridges/source/cpp_uno/msvc_shared/except.cxx(124,11): error: exception specification in declaration does not match previous declaration [-Werror,-Wmicrosoft-exception-spec] > RTTInfos::RTTInfos() throw() {} > ^ > C:/lo/core/bridges/inc\msvc/except.hxx(93,5): note: previous declaration is here > RTTInfos(); > ^ Change-Id: I7fa9d85de70d1398f89443b202b9b60c36dcc46a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104243 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-30bridges: add a Windows Arm64 UNO bridgeJan-Marek Glogowski11-5/+1414
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>
2020-09-27Fix typoAndrea Gelmini1-1/+1
Change-Id: I3792328b8e768d069e1a5a593cd811764bf7b5b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103492 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-23Add Stephan's "Very bad HACK" to the iOS code, too, for iOS 14Tor Lillqvist2-1/+42
Change-Id: Ie05d2dc77bfdcd323037d2e94b523808df4e1c9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102916 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102980 Tested-by: Tor Lillqvist <tml@collabora.com>
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-24 14:05:29 +0000