Age | Commit message (Collapse) | Author |
|
as in commit 9376f65a26240441bf9dd6ae1f69886dc9fa60fa
Change-Id: I3ad9afd4d113582a214a4a4bc7eea55e38cd6ff9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119927
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...similar to ca344be7aabf88dddde38841e6af6292ece6829b "tdf#143450: Fix special
fp+integer struct return case for gcc_*_x86-64"
Change-Id: Ia8110d632a1c5f328822c434efc5b09bd53ec9e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119883
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and
cid#1489552 Uninitialized scalar variable
Change-Id: I056cfd95d34f2163e68b83cce21bce70ccf5fc8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119701
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...to convince myself that it is only about the initial %rsp/%rbp fiddling, and
is not affected by the ca344be7aabf88dddde38841e6af6292ece6829b "tdf#143450: Fix
special fp+integer struct return case for gcc_*_x86-64" changes to later parts
of privateSnippetExecutor
Change-Id: I7bfad4cb5e1c2208e29c73a70874b6e9eff29eb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119610
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
For one, the loop in x86_64::fill_struct was backwards.
And for another, privateSnippedExecutor does not need special handling of FLOAT
and DOUBLE return values (they can simply be moved to %xmm0, as covered by the
general case), but rather for those small structs where floating-point member(s)
in a first eightbyte (targeting %xmm0) are followed by integer member(s) in a
second eightbyte (targeting %rax). Extended testtools to cover two such cases.
Change-Id: I8e775a1d1ce2312610f265bcc8e40b09bdac56df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119576
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
same as 5411aafbfd8656f043bcf30588bc41b061f1b60b "Clean up
bridges/source/cpp_uno/gcc3_linux_x86-64/abi.cxx"
Change-Id: I25ba66f2d666ef108265d308b7cc9badba60ae2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119579
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...without any intended functional changes, in preparation for actual fixes for
tdf#143450 "Data corruption when returning small structs containing a double
from C++ via IPC".
Much of the code (apparently originally copied from some other project,
according to the comments) was too generic for our specific needs here.
Change-Id: Iddcb58fa0999d10dcf716dd2af7dab1620839bce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119570
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This reverts commit 739aaf02db3353fac8490272cab0c9486570f76d. At least in
bridges/source/cpp_uno/gcc3_macosx_x86-64/except.cxx, getRTTI can call itself
recursively, causing a deadlock on RTTI::m_mutex. In
bridges/source/cpp_uno/gcc3_linux_x86-64/rtti.cxx that has been addressed with
RTTI::getRTTI_NoLock, but other implementations have not been modified. Avoid
regressions, esp. on more esoteric platforms, by reverting the change.
Conflicts:
bridges/source/cpp_uno/gcc3_linux_x86-64/rtti.cxx
Change-Id: I08b57b0561923bdbe191c8e93f8f400e0e4df337
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119442
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If56de2708254348b6b759ecdd2b1fb259562af69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119169
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I changed all the bridges to keep them in sync, but only
tested on the LibreOffice CI machines.
Change-Id: Id8fef017cc6c99c60d64b8f849220d5336abc5d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119140
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie973ef2923c1c725ee740000ebd1eacf671a5bfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119139
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: Ife669f959358992b547b408ab5d1f6bf1c1d14bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115744
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7eede75da6b81777661e0e5b76c8877e122f941b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115224
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
- 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>
|
|
Change-Id: Ib8951e9590d70ffecf8fd6af3070ef9c6d4ae151
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115044
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
Change-Id: I5c2420d5fb886926540bb3502c130404786f1698
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110641
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
/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>
|
|
Change-Id: I88140ab20440125d9642a1489e501cdcb74c3a48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107962
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I32276e3ceafa1e65671ba395de3f6fa587179d79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107878
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
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>
|
|
Change-Id: Idfb148fad55c7c6b6e6f4f4b5316fd3b086f7d2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107365
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I21202d25e4851725198c58c29d9820bda00f2b30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107315
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
Change-Id: Ice8b5ff4ddde1b0eca19cf29c418e3281389926d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105648
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I2d636f229ea52505cc263ea0219cf9f00130effd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104241
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If1cffd3896d87695ba189728d8c1f1f04d55b6b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104242
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I407b5e80a331950790f549ac8a50e8d7e49ee6d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104245
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2918d9ac8a4600bf5729604bda1beffb1dca78d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104244
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
> 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>
|
|
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: I3792328b8e768d069e1a5a593cd811764bf7b5b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103492
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|