summaryrefslogtreecommitdiff
path: root/bridges
AgeCommit message (Collapse)Author
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>
2021-10-28Revert broken optimization attemptStephan Bergmann
This partially reverts 1a5b12aa5da2c718848d3cc5d9bce7bfcdeacf54 "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
2021-10-13Extend return values < 32-bit on macOS ARM64Stephan Bergmann
<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>
2021-10-11In O[U]StringBuffer, make string_view params replacements for OUString onesStephan Bergmann
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That way, loplugin:bufferadd and loplugin:stringviewparam found many further opportunities for simplification (all addressed here). Some notes: * There is no longer an implicit conversion from O[U]String to O[U]StringBuffer (as that goes via user-defined conversions through string_view now), which was most noticeable in copy initializations like OStringBuffer buf = someStr; that had to be changed to direct initialization, OStringBuffer buf(someStr); But then again, it wasn't too many places that were affected and I think we can live with that. * I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to get them in line with their counterparts taking O[U]String. * I added an OUStringBuffer::lastIndexOf string_view overload that was missing (relative to OUStringBuffer::indexOf). * loplugin:stringconstant needed some addition to keep the compilerplugins/clang/test/stringconstant.cxx checks related to OStringBuffer::append and OStringBuffer::insert working. * loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related code that had been introduced in 1250aecd71fabde4dba990bfceb61bbe8e06b8ea "loplugin:stringviewparam extend to new.." Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-06tdf#130924 : replace debugging printf calls with SAL_INFO/SAL_WARNEmircan Agac
Change-Id: Ifede38f3b19d1e5226e18dba1aa21d478a430d9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120763 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-08-22WaE: protect clang diagnostic push/pop with if defined __clang__Caolán McNamara
Change-Id: I8360aa96097a13b6bad1283edddc7c2fd1ed510d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120832 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-21arm: fix bridgeCaolán McNamara
which went a little wrong in commit dd91d3389c26645459d3b80649941d65efa4f63f Date: Sat Jan 2 14:36:44 2021 +0100 Fix some warnings for Raspberry pi 4 (part3) Change-Id: Ief7e1146b7480a1c16ec0810f991296710214332 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120830 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-21arm: nStackBytes was already the right amount of bytesCaolán McNamara
possible regression from... commit 6e3424ca1131fe371f63e456267de476b5eb0eae Date: Sat Jan 2 11:03:12 2021 +0100 Fix some warnings for Raspberry pi 4 (part2) which changed that Change-Id: I9a19d7d6bc1e4115ffffbe32d8d62be5d275d500 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120747 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: René Engelhard <rene@debian.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-17rtl::Static -> thread-safe static localNoel Grandin
Change-Id: I9f8fe250813f4f376dc46c6f3d7e25e90fdbb50e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120566 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-03Consolidate on C++17 std::scoped_lock instead of std::lock_guardNoel Grandin
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>
2021-08-02tdf#143450: Special integre+fp struct return case needs a fix too, of courseStephan Bergmann
...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>
2021-07-30cid#1489551 silence Uninitialized scalar variableCaolán McNamara
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>
2021-07-28Annotate the .eh_frame dataStephan Bergmann
...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>
2021-07-28tdf#143450: Fix special fp+integer struct return case for gcc_*_x86-64Stephan Bergmann
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>
2021-07-28Clean up bridges/source/cpp_uno/gcc3_macosx_x86-64/abi.cxxStephan Bergmann
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>
2021-07-27Clean up bridges/source/cpp_uno/gcc3_linux_x86-64/abi.cxxStephan Bergmann
...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>
2021-07-27Revert "osl::Mutex->std::mutex in bridges/except"Stephan Bergmann
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>
2021-07-19flatten RTTI codeNoel Grandin
Change-Id: If56de2708254348b6b759ecdd2b1fb259562af69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119169 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-19osl::Mutex->std::mutex in bridges/exceptNoel Grandin
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>
2021-07-18osl::Mutex->std::mutex in VtableFactoryNoel Grandin
Change-Id: Ie973ef2923c1c725ee740000ebd1eacf671a5bfb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119139 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-29gbuild: implement gb_Library_get_target_for_buildJan-Marek Glogowski
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>
2021-05-19loplugin:noexcept (clang-cl)Stephan Bergmann
Change-Id: Ife669f959358992b547b408ab5d1f6bf1c1d14bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115744 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-07loplugin:noexcept (macOS)Stephan Bergmann
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 Glogowski
- 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 Bergmann
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 Bergmann
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 Grandin
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 formatHossein
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 READMEHossein
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 Glogowski
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 Lillqvist
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 Gelmini
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 Bergmann
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 Nabet
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 Nabet
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 Nabet
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 Nabet
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 Nabet
/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 Bergmann
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 Bergmann
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 Bergmann
...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 Bergmann
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 Bergmann
Change-Id: Idfb148fad55c7c6b6e6f4f4b5316fd3b086f7d2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107365 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2024-05-06 01:37:18 +0000