summaryrefslogtreecommitdiff
path: root/bridges
AgeCommit message (Collapse)Author
2023-08-03Fix handling of float vs. double valuesStephan Bergmann
...which had been broken ever since f424e55b4e66ffbee5b34f45ef5ea18d77c4d15c "INTEGRATION: CWS sixtyfour11 (1.7.22); FILE MERGED" had merged the typelib_TypeClass_FLOAT case into the typelib_TypeClass_DOUBLE case, and which caused > ==612573==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7fff4e6b0700 at pc 0x7f45a9d77d9e bp 0x7fff4e6af3f0 sp 0x7fff4e6af3e8 > WRITE of size 8 at 0x7fff4e6b0700 thread T0 > #0 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) at bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:155:51 (instdir/program/libgcc3_uno.so +0x118d9d) > #1 in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void*, void**, _uno_Any**) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233:13 (instdir/program/libgcc3_uno.so +0x112c1e) > #2 in unoInterfaceProxyDispatch at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:330:13 (instdir/program/libgcc3_uno.so +0x10e333) > #3 in stoc_corefl::(anonymous namespace)::IdlAttributeFieldImpl::get(com::sun::star::uno::Any const&) at stoc/source/corereflection/criface.cxx:141:9 (instdir/program/libreflectionlo.so +0x1f89e0) > #4 in non-virtual thunk to stoc_corefl::(anonymous namespace)::IdlAttributeFieldImpl::get(com::sun::star::uno::Any const&) at stoc/source/corereflection/criface.cxx (instdir/program/libreflectionlo.so +0x1fc5fb) > #5 in cppu::PropertySetMixinImpl::Impl::getProperty(com::sun::star::uno::Reference<com::sun::star::uno::XInterface> const&, rtl::OUString const&, com::sun::star::beans::PropertyState*) const at cppuhelper/source/propertysetmixin.cxx:563:24 (instdir/program/libuno_cppuhelpergcc3.so.3 +0x7d5059) > #6 in cppu::PropertySetMixinImpl::getPropertyValue(rtl::OUString const&) at cppuhelper/source/propertysetmixin.cxx:994:20 (instdir/program/libuno_cppuhelpergcc3.so.3 +0x7e462f) > #7 in reportdesign::OFixedText::getPropertyValue(rtl::OUString const&) at reportdesign/source/core/api/FixedText.cxx:143:34 (instdir/program/../program/librptlo.so +0x7452ad) > #8 in non-virtual thunk to reportdesign::OFixedText::getPropertyValue(rtl::OUString const&) at reportdesign/source/core/api/FixedText.cxx (instdir/program/../program/librptlo.so +0x7452eb) > #9 in rptui::OPropertyMediator::OPropertyMediator(com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&, std::__debug::map<rtl::OUString, std::pair<rtl::OUString, std::shared_ptr<rptui::AnyConverter>>, std::less<rtl::OUString>, std::allocator<std::pair<rtl::OUString const, std::pair<rtl::OUString, std::shared_ptr<rptui::AnyConverter>>>>>&&, bool) at reportdesign/source/core/sdr/PropertyForward.cxx:68:119 (instdir/program/../program/librptlo.so +0xbbbdb7) > #10 in rptui::OUnoObject::CreateMediator(bool) at reportdesign/source/core/sdr/RptObject.cxx:878:31 (instdir/program/../program/librptlo.so +0xc16451) > > Address 0x7fff4e6b0700 is located in stack of thread T0 at offset 4288 in frame > #0 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) at bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:50 (instdir/program/libgcc3_uno.so +0x1181d7) > > This frame has 3 object(s): > [32, 104) 'data' (line 53) > [144, 160) 'longs' (line 162) > [176, 192) 'doubles' (line 166) <== Memory access at offset 4288 overflows this variable > HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork > (longjmp and C++ exceptions *are* supported) > SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:155:51 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) > Shadow bytes around the buggy address: > 0x7fff4e6b0480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7fff4e6b0500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7fff4e6b0580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7fff4e6b0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7fff4e6b0680: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca > =>0x7fff4e6b0700:[04]cb cb cb cb cb cb cb 00 00 00 00 00 00 00 00 > 0x7fff4e6b0780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7fff4e6b0800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7fff4e6b0880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7fff4e6b0900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7fff4e6b0980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > ==612573==ABORTING when opening <https://bugs.documentfoundation.org/attachment.cgi?id=174542> Example2Fields.odb attached to <https://bugs.documentfoundation.org/show_bug.cgi?id=144072> "LibreofficeBase crashed when 2 fields selected in report builder from different sections and width is adjusted 2nd time" and clicking "Edit..." in the context menu of the "RptTasks" report. Change-Id: I318765aede68353d475a0d672e0aea36ed12af29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155286 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-31fix 32 bit int simple return of riscv64 bridgeSakura286
Sometimes we need to return a 32 bit integer into a 64 bit integer. For example, in pyuno.cxx:PyUNO_bool(), an int(32bit) is returned in type Py_ssize_t(64bit). We assume that this 32bit int was put in low 32 bit of register a0. The bridge may return with high 32 bit uncleaned and compiler might directly bind this register to 64 bit variable in error. This bug produces when build pyuno with gcc-12 with -O2. https://bugs.documentfoundation.org/show_bug.cgi?id=155937 https://lists.debian.org/debian-riscv/2023/07/msg00011.html So we need to clean the high 32 bit in bridge. Change-Id: I37aafb03ba9523cfb90912871308921fbeaf5f0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154837 Tested-by: René Engelhard <rene@debian.org> Reviewed-by: René Engelhard <rene@debian.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-31fix CustomTarget_uno_test check failed with enable java on loongarch64wujiahuan
Change-Id: Iadb1f16eb10761cdef392110986bddda44ddee3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154833 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-04-20Fix compilation with latest Xcode with iOS SDK 16.4Tor Lillqvist
Alternatively we could just remove lots of stuff that we apparently don't actually need from this file, including the problematic typedef and its uses. _Unwind_Exception_Class now gets typedeffed in <unwind_itanium.h> as uint64_t which effectively is the same as the unsigned __attribute__((__mode__(__DI__))) that is used here. Change-Id: Id96d43eb481ee4ae97dd315aa2fd741e5f627916 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150702 Reviewed-by: Patrick Luby <plubius@neooffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2023-04-19win/aarch64: fix offset loading simple values into the registersChristian Lohmaier
the stack variable doesn't point to the beginning of the array with the values, instead the code creates a large general purpose register array (gpr) with the floating point register (fpr) and stack just being offsets in that one. bridge isn't fully working with that fix yet, still some wrong pointers ending up in the interface reference Change-Id: I6f1e5f84f84aff34663090c20fe70d65e0a7a334 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150578 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2023-04-17loplugin:stringaddStephan Bergmann
Change-Id: I10b450bccf27304530767cf80e0a6b04768cfc80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150468 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-04-11loplugin:stringaddStephan Bergmann
Change-Id: Ib35058e0e8d1708c29f4fe727eda05f5a6de4ab4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150232 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-24loplugin:stringadd in b*Noel Grandin
after my patch to merge the bufferadd loplugin into stringadd Change-Id: Ieb9b4f5154173738e26b429b55c7a3ea38733553 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149478 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-22bridges: drop unnecessary debug messageIlmari Lauhakangas
Change-Id: I4c08ea2e464164351ba66a4c04ef2575e3f5f580 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149157 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-22tdf#130924 : replace debugging printf calls with SAL_INFO/SAL_WARNYousef_Rabia
Change-Id: I94686f820e264867643bb30c83367ee702d3118d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149088 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-18tdf#130924 replace debugging fprintf calls with SAL_INFO/SAL_WARNektagoel12
Change-Id: I1893e130af2584c1d57c3e37ee3f3ff18c07c077 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148792 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-03-18bridges: add whitespace to SAL_INFOIlmari Lauhakangas
Missed in 7a8ec6cddc9f37ba6ff1a98ad39702521c8fb36b Change-Id: I70b73873f20814d25c34f326a6552e72f57b3e28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149081 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-03-02bridge linux x86-64 : remove useless includesArnaud Versini
Change-Id: Ibd3b9a76b700a5efbf7855454714646daf612d13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147675 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-16android: Switch from GNU binutils to support NDK 23.x, require 21.xMichael Weghorn
Relevant announcement from revision history for NDK 23 [1]: > * GNU binutils, excluding the GNU Assembler (GAS), has been removed. GAS > will be removed in the next release. If you are building with > -fno-integrated-as, file bugs if anything is preventing you from > removing that flag. Therefore, switch from uses of GNU binutils to the corresponding LLVM tools instead. NDK 20.x doesn't provide `llvm-ranlib` yet, so bump the minimum version to 21.x. Also drop the previous uses of `ANDROID_BINUTILS_PREBUILT_ROOT`, which appear to no longer be relevant by now. commit 4082a18406c18af7b4fcef7bd501c3679c3be56b Date: Wed Nov 22 23:08:06 2017 +0100 android: use unified headers and llvm-c++ STL (x86) with NDK 16 gnustl (and others) are to be removed in future versions of the ndk also bump gradle and build-tools to current versions along with it arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix that later that introduced one of those uses mentions issues on ARM, but building and running the app at least on my 32-bit ARM device (Samsung Galaxy S4 I9505, LineageOS 17.1/Android 10) didn't show any issues in a quick test with this change in place. Update the Jenkins config to switch from the now no longer supported NDK 20.1.5948944 to 23.2.8568313 for which building and running the app has been tested on devices for all of the four supported architectures with upcoming change Change-Id I9ea714255faf29d50bb5f8e206f13495637da867 "android: Require NDK 23 and use default linker lld" in place on top, s. that one's commit message for more details. Note however that the NDK version will be further updated to use NDK 25 in upcoming change Change-Id Ib8e65f433ee89ff1bc12432722570bf8f9f7ed85 ("android: Support NDK 24.x and 25.x, use NDK 25 for Jenkins"). [1] https://developer.android.com/ndk/downloads/revision_history [2] https://lists.freedesktop.org/archives/libreoffice/2023-January/089878.html Change-Id: I7645f8025d42f0fa384b5bceb31bb4b1c0a44cb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146118 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Michael Weghorn <m.weghorn@posteo.de>
2023-02-02osl::Mutex->std::mutex in JniUnoEnvironmentDataNoel Grandin
Change-Id: Iab6d430af7afc0d21e118b05d64a15664fc2f677 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146469 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-01osl::Mutex->std::mutex in ExceptionInfosNoel Grandin
Change-Id: Ic947b58b9aba121c605b6795c7cd9aa0b16b180e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146455 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-27Remove Solaris 32-bit SPARC and x86 C++ UNO bridge implementationsStephan Bergmann
As discussed in the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html> "Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)", the bridge implementations at bridges/source/cpp_uno/gcc3_solaris_intel and bridges/source/cpp_uno/gcc3_solaris_sparc are apparently dead and should thus be removed. Those were the only bridge implementations for Solaris, but the referenced thread mentions that there are recent builds for OpenIndiana x86-64 (however they are done; presumably using bridges/source/cpp_uno/gcc3_linux_x86-64), so keep general support for Solaris intact for now. Change-Id: I09ec098f5509f25a126342536745509bbe9faaac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146059 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-27Remove support for 32-bit S390Stephan Bergmann
As discussed in the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html> "Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)", the bridge implementation at bridges/source/cpp_uno/gcc3_linux_s390 is apparently dead and should thus be removed. However, that was the only bridge implementation for 32-bit S390, which implies that support for the 32-bit S390 architecture as a whole is dead and should thus be removed. Change-Id: I18b3b4fa11df4ce693107bad6bbea2fab1c19f26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146058 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-27Remove support for AIXStephan Bergmann
As discussed in the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html> "Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)", the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is apparently dead and should thus be removed. However, that was the only bridge implementation for AIX, which implies that support for the AIX platform as a whole is dead and should thus be removed. Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-11bridges:Fixed test fail caused by bridges on the loongarch64wjh-la
Some failed test are caused by the bridges when testing on the loongarch64 machine. After adjust the function parameters and return value processing according to the characteristics of the loongarch64 architercture. I tested in version 7.4.3 on the loongarch64 machine, and all tests passed. Change-Id: I9c67287cd7cc89fd79a907afdbffa507bb6052e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144986 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-04Rudimentary support for dynamic_cast on UNO proxy objectsStephan Bergmann
<https://gerrit.libreoffice.org/c/core/+/144139> "New loplugin:unocast" had argued that uses of dynamic_cast from a UNO interface type are broken in general (because if the source object is a proxy from the C*+ UNO bridge, its vtable's RTTI slot will normally not be set up, which can cause a crash), and should be replaced with uses of XUnoTunnel. Which the various recent "loplugin:unocast (...)" commits started to do. However, it became clear that that is not the most ideal way forward: For one, getting more and more implementations of XUnoTunnel::getSomething into existing class hierarchies is error prone, as each such implementation must manually delegate to all its base class implementations. For another, uses of comphelper::getFromUnoTunnel (which often needs to do a queryInterface to XUnoTunnel first) are easily more expensive than uses of dynamic_cast. Thanks to Noel, the insight here is that for the use case of a dynamic_cast from a UNO interface type to a local C++ class type, and if the source object is a proxy, it is sufficient that the dynamic_cast will not crash. It will necessarily always return null (as the proxy will never be the implementation of a local C++ class type), so it is sufficient to fill the RTTI slots of the proxies' vtables with dummy values. That avoids having to set up proper RTTI for those potentially multiple-inheritance proxy types. (And with this in place, all those recent "loplugin:unocast (...)" commits can be reverted again in a next step.) I verified the changes for the gcc3_linux_aarch64 (on macOS), gcc3_linux_intel, gcc3_linux_x86-64, gcc3_macosx_x86-64, msvc_win32_intel, and msvc_win32_x86-64 bridges. The changes for all the other bridges were done blindly. (For gcc3_linux_x86-64, which already conditionally supported proper RTTI for UBSan, setting the offset-to-top slot to non-zero had to be made conditional too, as the dummy ProxyRtti will always pretend to be a full class rather than a potential base class that could have a non-zero offset-to-top value. For msvc_win32_*, it turned out that the existing code to set up dummy XInterface RTTI (which was there for reasons lost to history) was broken.) Change-Id: Iec4b8067d26b14b6fb02c2fdd15e1eee20919590 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145038 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-04Fix Itanium vtable constructionStephan Bergmann
Our use of bridges::cpp_uno::shared::VtableFactory::Slot to model all the elements of a vtable is an abstraction that doesn't quite match the reality of <https://itanium-cxx-abi.github.io/cxx-abi/abi.html>, as vtables are not homogenous sequences of function pointers, but are rather a mix of offsets, data pointers, and function pointers. The data preceding the virtual table address point is the offset to top (an offset) followed by the typeinfo pointer (a data pointer). On other platforms where offsets, data pointers, and function pointers are all of the same size, we model those as two additional Slots at index -2 and -1, resp. On Itanium, where function pointers (and thus Slots) are twice the offset and data pointer size, we should model those as one additional Slot at index -1. The code has been this way ever since its introduction in 0c25631972809c752624b4883c71671c8e83e797 "INTEGRATION: CWS ia64port01_DEV300 (1.1.2); FILE ADDED". It should never have caused any issues as the existence of the excess Slot at index -2 should never have gotten in the way. But it is probably better to clean this up anyway. (This is a blind fix, as I don't have an Itanium build environment available. And this Itanium bridge may well be dead code by now, anyway.) Change-Id: I98d58785c054e1cdc621e5968c41b06d8788998f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145035 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-10Add riscv64 supportSakura286
1. Configure gbuild 2. Add UNO Bridge for riscv64 Till now base function works well on riscv64. The bridgetest has passed. Test on Debian, Gentoo and openEuler. Credits: - Heiher <r@hev.cc> and Stephan Bergmann <sbergman@redhat.com> The riscv64 bridge implementation refers to mips64 and AArch64 bridges. - Bo Yu <tsu.yubo@gmail.com> configures gbuild for riscv64. - WANG Xuerui <xen0n@gentoo.org> provides lots of guiding tips. Change-Id: Ifad3b0de8b2c9e7328627ed03396bbd45a9c71e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137445 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2022-10-11Deduplicate O(U)StringConcatenationMike Kaganski
And use an overloaded helper function with a better (?) unified name to show that the result is not an O(U)String. Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-09-07Fix register clobber information and simplify in the C++/UNO bridge for iOSTor Lillqvist
Avoid the use of unnecessary local variables to temporarily keep return values from a function called by the inline assembly. Instead use the GPR and FPR arrays also to temporarily keep such return values, like the Linux aarch64 code does. This fixes https://github.com/CollaboraOnline/online/issues/5204 Change-Id: I11aac56e9c8cc8aff1a3653ced45bdf4844cbcca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139604 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2022-08-22cid#1500671 silence Resource leakCaolán McNamara
Change-Id: I295d7877100b49a867a0f67e2edcc923d943401b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138664 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-22cid#1500470 silence Resource leakCaolán McNamara
Change-Id: I846746a351c619a4de7abce7a6443f510dc41690 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138661 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-17cid#1500585 Dereference before null checkCaolán McNamara
Change-Id: I9374a580d3dce7c7851881ff8193946d46ed2bec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138384 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-13bridges/jni : remove useless using and use css instead of com::sun::starArnaud VERSINI
Change-Id: I1b73d68b007ba0dfa54f99ff8f8fea55e94a1ed2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137651 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-11Add loongarch64 support.wjh-la
Loongarch is a new RISC ISA , which includes a 32-bit version and a 64-bit version, Here are some documents about Loongarch： https://github.com/loongson/LoongArch-Documentation. The loongarch64 bridges implementation refers to mips64 bridges, and the code related to abi and asm has been modified Change-Id: I1d9cd3aadf63046c8cdecc9a64842567bfa1cecc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137486 Tested-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-08-10Better cast to sal_[u]IntPtr when passing pointer to O[U]String::numberStephan Bergmann
Change-Id: I5b7a0fa060c1e0ae4aa194e0c1862f303dd8a2d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138062 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-07-27rename GODSON/GODSON64 to MIPS/MIPS64Rene Engelhard
as that what it actually is and the compiler defines are already -DMIPS/-DMIPS64 anyway (as are the PLATFORMID and the bridges' name mips/mips64) Change-Id: I274e7a3b0e140375a8e697c1790cbdb972251d29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137489 Tested-by: René Engelhard <rene@debian.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: René Engelhard <rene@debian.org>
2022-07-10tdf#143148 Use pragma once instead of include guardsam.faraji
Change-Id: I7bd02dba44a8bc62da660bcb7500960ef14172a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136939 Tested-by: Hossein <hossein@libreoffice.org> Reviewed-by: Hossein <hossein@libreoffice.org>
2022-06-21elide some makeStringAndClear() callsNoel Grandin
Change-Id: Ie8c04a8c414f32cc0e68fbab1d24a9707f179011 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136201 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-21clang-tidy modernize-pass-by-value in bridgesNoel Grandin
Change-Id: I6c52316e46117aacb22a2adcb75841aed834041f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134705 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-05use more o3tl::getTokenNoel Grandin
found by inspecting call sites of OUString::getToken Change-Id: I4269c7476c7aa46fac39528227e350568f0eb34a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132644 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-25loplugin:stringviewStephan Bergmann
Change-Id: I4bd3efe67217a4c4418cf308cc8e7a55cf4a604a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133390 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-22use more string_view in bridgesNoel Grandin
Change-Id: I842668655dec102e1595dcbac6413fe2b49d8515 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133268 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-25bridges : use std::mutex in java brigeArnaud Versini
Change-Id: I07b215067b1cefc87919680fad3299d702ff6d1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132100 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-08Drop some debug codeStephan Bergmann
...that had been introduced with 7e8e85adbee73346403c364326544487677cd5c6 "Add codeSnippet debugging output when dbglevel>1" and reinforced with 6f121860d0537060084278da11842732a748d6b7 "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>
2022-03-05tdf#130924 replace debugging printf calls with SAL_INFO/SAL_WARNpragat-pandya
Change-Id: Iaef5eec6508d031ab711a71c0d8ecebb18112ef6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130764 Tested-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-03Avoid loplugin:noexceptStephan Bergmann
...when building on Linux with Clang -stdlib=libc++, > In file included from bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:41: > bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx:156:51: error: Replace legacy dynamic 'throw ()' exception specification with 'noexcept' [loplugin:noexcept] > extern "C" __cxa_eh_globals * __cxa_get_globals() throw(); > ^~~~~~~ (The situation with respect to these exception specifications is a bit unclear, recent <https://github.com/itanium-cxx-abi/cxx-abi/blob/main/abi-eh.html> doesn't mention any exception specifications for those effectively extern "C" functions, and recent <https://github.com/llvm/llvm-project/blob/main/libcxxabi/src/cxa_exception.h> doesn't have an exception specification for __cxa_get_globals and recent <https://github.com/llvm/llvm-project/blob/main/libcxxabi/include/cxxabi.h> doesn't have one for __cxa_current_exception_type though it has `throw()` for __cxa_allocate_exception. On the other hand, recent <https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/libsupc%2B%2B/cxxabi.h> and <https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/libsupc%2B%2B/cxxabi_init_exception.h> have _GLIBCXX_NOTHROW exception specifications for all three functions, which expands to `noexcept` for C++11 and beyond.) Change-Id: I1582c9d3b42977af011d4dc49674fdf12d5ea5ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130926 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-19WASM UNO: add a minimal dummy bridgeThorsten Behrens
... 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>
2022-01-15Let loplugin:nullptr look into template instantiationsStephan Bergmann
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>
2022-01-06annocheck warning about missing .note.gnu.property sectionCaolán McNamara
copy and paste recommendation from: https://sourceware.org/annobin/annobin.html/Test-cf-protection.html and adapt like: https://github.com/openssl/openssl/commit/51994e505dbb1cd0dd76869ec962e2948b77b585 where https://bugs.ruby-lang.org/attachments/8962 is similar Intel docs have "The ENDBR32 and ENDBR64 (collectively ENDBRANCH) are two new instructions that are used to mark valid indirect CALL/JMP target locations in the program." Change-Id: Ie867c263a888763db4478720ba189c9ec6cc974d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126859 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-01-01Android Arm: fix wrong bracket after refactorJan-Marek Glogowski
How did that even pass in Jenkins on Android Arm? Regression from commit c859b4aa48956cbf5ff41280b0008456e8f5189c ("gbuild: introduce gb_%_linktarget_target"). Change-Id: Id06cc151e92e221da856814d69eb8cced167b427 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127829 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-31gbuild: introduce gb_%_linktarget_targetJan-Marek Glogowski
Just some refactoring. Change-Id: I47adb93f8a413d289f6abb2a48ed3f049f582a46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127799 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-24bridges : remove redundant publicArnaud VERSINI
Change-Id: I836412674448acb2a047d3d8b4711fa8d0b67257 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127410 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-20bridges : use std mutex instead of osl::Mutex.Arnaud VERSINI
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
2021-12-01gbuild: introduce plugin + loader conceptsJan-Marek Glogowski
This introduces two concepts: a plugin and its loader (library) LO currrently has dependency cycles for some libraries. There is scui, which depends on sc, while sc dlopen's scui. There are the various vclplug_*, i18npool plugins, filters/gie, acc, etc. Usually these plugins link to their loader library, because they use its symbols. But as a result there is no sensible way to express the runtime dependency of loaders on the plugins. In GNU libtool plugins are called modules and they are implemented in an IMHO more sensible way by allowing missing symbols at link time. This way you can have a dependency from the loader library to its plugins, as the plugins don't depend on the loader, but you lose the link time detection of missing symbols. While this is in theory possible in LO too, LO currently has plugins, like acc (accessibility), loaded by tk (toolkit), which depends on svt (svtools), which itself depends on tk, so dropping the tk dependency for acc on its own doesn't help :-( And while the dependency of the plugins on their loader is fine for the shared / DYNLOADING build, for the "static" builds you must (somehow) link the plugins into the executables. I also codeified a few rules into the build system along with it: * just plugins are allowed to depend / link other plugins * plugins aren't allowed to be linked into the merge lib * plugin loaders are "limited" to libraries At the high level, this is implemented via new gbuild calls: * gb_Library_set_plugin_for,lib,loader: declare a library to be a plugin of a loader library and add a dependeny from the plugin library to the loader library * gb_Library_set_plugin_for_nodep,lib,loader: ^^^^ without adding the library dependeny * gb_Helper_register_plugins_for_install: "plugin" replacement for gb_Helper_register_libraries_for_install to implement some additional checks in the build system In the end this patch just adds a bit syntactic sugar and nothing changes for any build. Change-Id: I7b01d9c384cbc5838bd2cc93aff18e4868939d6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126163 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
generated by cgit (git 2.34.1) at 2024-12-29 03:04:56 +0000