...that had been introduced with 7e8e85adbe "Add
codeSnippet debugging output when dbglevel>1" and reinforced with
6f121860d0 "tdf#130924 replace debugging printf
calls with SAL_INFO/SAL_WARN"
Change-Id: I9529bfdedd3d1a3dd623fdb28e01d6bd96c92d97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131169
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... and use the same fake exception rethrowing code then the
mobile platforms.
Change-Id: Ic90de1cfd1e0092d6064d041a613d60d9f5f76b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128596
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
It missed some occurrences of 0 when only looking into uninstantiated template
code, as Clang doesn't model them with an ImplicitCastExpr, even if the target
is known to be a (dependent) pointer type.
Looking into all template instantiations of course carries the risk that a given
use of 0 is meant to be interpreted as a pointer in some and as an integer in
other instantiations. But the only case where that happened in the current code
base is RegistryValueList::getElement (include/registry/registry.hxx), where {}
is arguably a better choice anyway. (And which would presumably also hold for
any future such cases.)
Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The lock_guard moved from RTTI::GetRTTI to x86_64::getRtti to avoid recursive lock.
Change-Id: I0e71581dd57a4fb2655d4b9040fb9d943f73ab9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127095
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
This partially reverts 1a5b12aa5d "optimise
find/insert pattern", which caused
> ~/llvm/inst/bin/../include/c++/v1/unordered_map:1134: _LIBCPP_ASSERT '__get_const_db()->__find_c_from_i(&__p) == this' failed. unordered_map::insert(const_iterator, const value_type&) called with an iterator not referring to this unordered_map
during CustomTarget_testtools/uno_test in an experimental build with
-D_LIBCPP_DEBUG=1 on macOS.
Change-Id: Id40e5eab7c3fb1f8e1bb2599c7fb84649e870ba2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124319
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
<https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Pass-Arguments-to-Functions-Correctly>
only mentions function arguments, not return values in "The caller of a function
is responsible for signing or zero-extending any argument with fewer than
32 bits. The standard ABI expects the callee to sign or zero-extend those
arguments." But this appears to also be relevant for return values, where the
callee apparently has to provide properly extended values: Without this change,
in an --enable-optimized build, e.g. selecting "Tools - Macros - Organize Macros
- BeanShell... - LibreOffice Macros - Capitalize - capitalize.bsh" would not
enable the "Run" button, as in SvxScriptOrgDialog::CheckButtons
(cui/source/dialogs/scriptdlg.cxx) node->getType() (which returns a sal_Int16
value, and which calls DefaultBrowseNode::getType,
scripting/source/provider/BrowseNodeFactoryImpl.cxx, which in turn calls
m_xWrappedBrowseNode->getType() on a proxied Java object via the UNO bridge)
would return a value in r0 with bits > 16 left with random values, while the
calling code assumes them to be zero (and exploits that violated assumption with
--enable-optimized).
Change-Id: Ic99dd9e62b49b44e13cdde6158bef7e2296547f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123550
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
...to convince myself that it is only about the initial %rsp/%rbp fiddling, and
is not affected by the ca344be7aa "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>
...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 739aaf02db. 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>
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>
/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>
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>
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>
Stephan Bergmann