summaryrefslogtreecommitdiff
path: root/bridges
AgeCommit message (Collapse)Author
2024-07-11Rename wasmcallgen -> wasmbridgegenStephan Bergmann
...to acknowledge the tools' more general role since 74829f2a64b6989ddf1d126a6fd2f2d2e9000d3b "Fully implement the Wasm UNO bridge cpp2uno direction" Change-Id: Ie89255579774035f7b726d1d4b029dc536893ca0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170382 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-07-11Fully implement the Wasm UNO bridge cpp2uno directionStephan Bergmann
...after 875997c8962da7f6b72950b201186a19b3c20d3a "Properly implement cppu::throwException for Emscripten" had implemented only those parts that were absolutely necessary for that exception throwing. As detailed in the commit message there, wasmcallgen has been extended to additionally generate all the required vtable slot call trampoline code (which cannot be generated on the fly for Wasm, as would be done for other platforms). Consequently, some of the "callvirtualfunction"-centric file names have been changed to "generated" as the output of wasmcallgen is now more general. (And wasmcallgen itself should also be renamed, in a follow-up commit. And when adding to the wasmcallgen code here, some existing parts of its implementation have been cleaned up, too.) There is no direct way to test this half of the Wasm UNO bridge directly from unotest/source/embindtest/embindtest.js, so a new org.libreoffice.embindtest.BridgeTest singleton has been added, which triggers new test code in unotest/source/embindtest/embindtest.cxx that tests the bridge in a way similar to testtools' bridgetest machinery. Change-Id: I521a1d6c2160aedc814f7603b0b99861e5fbd1eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170374 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-10Consolidate common codeStephan Bergmann
Change-Id: Ic24163970fd5b97c2426f0786d9b7d97a1796f87 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170309 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-07-10Properly implement cppu::throwException for EmscriptenStephan Bergmann
...by implementing (for now) just enough of the cpp2uno half of the Wasm UNO bridge to make it work. In general, that half suffers from the same issue as the already-implemented uno2cpp half, namely that Wasm doesn't allow to generate code on the fly (which, in this case, would be needed to implement the vtable slot trampoline functions). So, for now just hard-code the few vtableSlotFunction_* that are needed by the UNO interfaces for cppuhelper/source/exc_thrower.cxx. (A proper fix would probably use the same approach as for the uno2cpp half, and use something like wasmcallgen to generate at least all the vtableSlotFunction_* needed for udkapi/offapi upfront.) The RTTI for the exceptions needs to be unique across the executable for exception catching to actually work (as it compares exception types by RTTI address rather than by name). We thus need to export all the relevant RTTI symbols (which I hacked into the existing wasmcallgen for now, even if that makes that executable's name a slight misnomer now), and access them with a new jsGetExportedSymbol. (This exporting would also be needed by the "classical" approach of using dlsym on the main module, cf. <https://gerrit.libreoffice.org/c/core/+/167187> "WIP: Emscripten: Set up support for dlsym from main module". And while that dlsym approach would work, it is much simpler to just use that jsGetExportedSymbol than to use a dlsym detour, and thereby avoid all the hassle of -sMAIN_MODULE detailed in the commit message of that Gerrit change.) It also turned out that including Emscripten's <cxxabi.h> needs __USING_WASM_EXCEPTIONS__ to be defined, because it uses that in its declaration of __cxa_throw. (The source for setting that define internally in Emscripten is get_cflags in the emsdk's upstream/emscripten/tools/system_libs.py, which defines __USING_EMSCRIPTEN_EXCEPTIONS__ for the non-Wasm, Emscripten JS exception mode, and defines __USING_WASM_EXCEPTIONS__ for --enable-wasm-exceptions, which we use. The commit message of f4ec967599f5dafa1ce477631d7c2e8de005e28f "Fix redefinion of Emscripten __cxxabiv1::__cxa_exception" documents my prior confusion of when one or the other would be defined.) Change-Id: Id08765ab5b4ce1553dc3a61648324526185cb64c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170246 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-21Embind: Fix C++ UNO exception catchingStephan Bergmann
...with a new Module.catchUnoException JS function that can be used in a JS catch block to provide the thrown UNO exception as an Any. (For a non-C++ exception, it rethrows the exception, and for a non-UNO C++ exception it maps it to css.uno.RuntimeException.) The implementation reuses parts of bridges/source/cpp_uno/gcc3_wasm/, which have been moved to a new StaticLibrary_emscriptencxxabi. Change-Id: I708fe6121c43a1b9736de5dff449f6c4f32a45f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169325 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-21Don't expect _LIBCXXABI_DTOR_FUNC to be availableStephan Bergmann
...as apparently happens to be the case with some older emsdk versions, see <https://ci.libreoffice.org//job/lo_daily_tb_linux_wasm/743/> choking on that Change-Id: Ie2f4b9684c794fdd51142eb81d96dd3332911272 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169319 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-20Fix redefinion of Emscripten __cxxabiv1::__cxa_exceptionStephan Bergmann
<https://github.com/emscripten-core/emscripten/> system/lib/libcxxabi/src/cxa_exception.h has two different definitions of that struct, a short one for when __USING_EMSCRIPTEN_EXCEPTIONS__ is defined, and a long one for the other case. In 7175431a4b2154113c2c3c28f7ae8a8f14a84c7a "Implement exception catching", I had naively copied the short version, assuming that __USING_EMSCRIPTEN_EXCEPTIONS__ was something that sounded like it would be defined with --enable-wasm-exceptions. But some debugging of actual exception handling now showed that the assumption had apparently been wrong (though I still have no idea about the semantics of that __USING_EMSCRIPTEN_EXCEPTIONS__ define, and when it would or would not be defined), and that I had copied the wrong version. The relevant test code > try { > const ret = invoke.invoke('throwRuntimeException', params, outparamindex, outparam); > console.assert(false); > ret.delete(); > } catch (e) { > const [type, message] = getExceptionMessage(e); > console.assert(type === 'com::sun::star::reflection::InvocationTargetException'); > console.assert(message === undefined); //TODO > //TODO: inspect wrapped css.uno.RuntimeException > decrementExceptionRefcount(e); > } in unotest/source/embindtest/embindtest.js had apparently happened to not cause a crash with the wrong version of __cxxabiv1::__cxa_exception, but had also happened to not detect the mistake due to the relevant parts being commented out with TODO (because, in turn, proper UNO exception catching is still lacking in our Embind-based JS binding). Change-Id: I718087c7ed2c17808696267ece17237d5cdf2f54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169305 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-19Fix typoAndrea Gelmini
Change-Id: I4750989bffaa95c652fe5f90962342638296b026 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169156 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2024-06-19Fix typoAndrea Gelmini
Change-Id: Ia7e36299a15fd4096f2e8e50efad2e8e1b61bec9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169166 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2024-06-19Fix typoAndrea Gelmini
Change-Id: I392dc943c4a423ca6bd7c3a3efd2a68adb75bf1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169176 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-05-31Clean up using directivesStephan Bergmann
Change-Id: Iaf343b3dabec951e1fd2d998a11fca8f593afdb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168260 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-05-30Implement attribute handlingStephan Bergmann
Change-Id: Ic30d2de582f952555ec672984da78a07a9319443 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168224 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-05-29Clean up gcc3_wasm bridge_noopt_objectsStephan Bergmann
There appears to be no good reason that cpp2uno.cxx and uno2cpp.cxx are noopt (presumably that was just cargo-culted from another platform?), and except.cxx appears to be completely unused anyway. Change-Id: Ic5f4142308a56b798dad61e9ec589046cad2ae13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168182 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-05-29Implement exception catchingStephan Bergmann
(Without 22ce8ed05be37d676739a578b05cc5217109fd87 "Emscripten: Unconditional --enable-wasm-exceptions", this would have failed to link due to missing __cxa_current_exception_type and __cxa_get_globals.) Change-Id: If89a3c62e4d2ac24d68f867b2fd7a4cd813d5a39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168176 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-05-11WaE: C6011 Dereferencing NULL pointer warningsCaolán McNamara
Change-Id: Iab647d1f98bb532bc0a2c42971e747708e52a875 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167495 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-09Fix missing UNO<->C++ argument/return value conversionsStephan Bergmann
Change-Id: I5ac6013d6c0bd72fe840a592628fd0d5b265b8ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167391 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-05-09Fix typelib_TypeDescriptionReference -> typelib_TypeDescription conversionStephan Bergmann
Change-Id: Idfe74f1523ec866ed9926d3385a1605ad8a5547e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167352 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-05-08Move call code out into a function of its ownStephan Bergmann
...so that it can be reused in the future for attribute getters/setters Change-Id: I3dde796eb0c2f3812b7aee1a2c000bad31b33158 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167345 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-05-08Emscripten: Towards a working C++ UNO bridgeStephan Bergmann
...by making the general UNO -> C++ function call case work (modulo handling exceptions, which I'll look into later). Wasm call_indirect unfortunately needs to statically know the call target's signature, so we statically need to know all possible signatures. So introduce wasmcallgen helper to scan the existing UNOIDL API upfront and generate the relevant callvirtualfunction-wrapper.cxx and callvirtualfunction-inst.s code. (The good thing is that the number of different signatures is somewhat limited, each parameter can only be one of i32, i64, f32, or f64. So even if 3rd-party extensions bring along new UNOIDL interface methods, chances are relatively high that the signatures needed for them would already be covered by the existing ones.) Testing this can nicely be done in unotest/source/embindtest/embindtest.js via css.script.Invocation (which internally exercises the relevant code). (Instead of adding individual org.libreoffice.embindtest.StructLong/String etc., it would be nicer to introduce some polymorphic StructOne<T>, but the Emind UNO binding does not support polymorphic structs, so the embindtest.js code would not work.) Change-Id: If829c9e3772bfd27561f3ad743d38a71d11545b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167308 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-05-06loplugin:ostr in bridgesNoel Grandin
Change-Id: I6e0b9006924f058aceb2b0a4639f6987cec314a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167204 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-03makefile simplification: replace $(call gb_CustomTarget_get_workdir,foo)Christian Lohmaier
…by a simple/static $(gb_CustomTarget_workdir)/foo The build system has a lot of overly complicated leftovers from when it was introduced and had not only deal with split repositories but also had to coexist with another buildsystem. Along with lots of copy'n'paste along the years the makefiles became hard to grasp for newcomers with all our calls and evals. As a first step to streamline that, the macros from TargetLocations that simply prefix a static path to the argument (and similar of the same kind) are a natural pick before simplifying the rules themselves/getting rid of a bunch of eval statements. Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-04-30WaE: C6011 Dereferencing NULL pointer warningsCaolán McNamara
Change-Id: I498c10e8bc134b41e3606d8a05cf3103a9274735 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166937 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-04-26Drop unused RETURN_KIND_HFA_FLOAT/DOUBLE from msvc_win32_arm64 UNO bridgeStephan Bergmann
Change-Id: I8c6fbed8c587affda69285c203a3a93fa2e2e603 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166699 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-25Adapt queryInterface in fixed msvc_win32_arm64 UNO bridgeStephan Bergmann
...where the function's argument is in x2, not x1 (see commit message of ae6ee262d7649222a137f8722886a10db274ddf5 "Some fixing of msvc_win32_arm64 UNO bridge" for details) Change-Id: I00ef5df1ebad4609918c0c6845ebdcfe810f6152 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166622 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-25Add back the callVirtualFunction_fake boilerplateStephan Bergmann
...that ae6ee262d7649222a137f8722886a10db274ddf5 "Some fixing of msvc_win32_arm64 UNO bridge" had removed, assuming it wasn't actually necessary. But looks like Windows exception handling stack unwinding somehow needs it after all. Getting past the CustomTarget_testtools/uno_test getRaiseAttr1() call now (but still failing at some later place). Change-Id: I1e84345f2f355ab1e480c779da6b221b744132b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166616 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-04-24Some fixing of msvc_win32_arm64 UNO bridgeStephan Bergmann
For one, the Windows ABI deviates from the generic aarch64 ABI regarding returning class instances by value from non-static member functions, see <https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#return-values>: "The caller shall reserve a block of memory of sufficient size and alignment to hold the result. The address of the memory block shall be passed as an additional argument to the function in x0, or x1 if $this is passed in x0. The callee may modify the result memory block at any point during the execution of the subroutine. The callee returns the address of the memory block in x0." That means RETURN_KIND_HFA_FLOAT and RETURN_KIND_HFA_DOUBLE are not needed, and can be cleaned up in a follow-up commit. And for another, setting up a call stack frame in call() in uno2cpp.cxx for callVirtualFunction() didn't actually work, so go with a slightly less ambitious aproach (as also used by the gcc_linux_aarch64 bridge) and explicitly copy the arguments that end up on the stack around in callVirtualFunction(). This allows CustomTarget_testtools/uno_test to proceed at least as far as the call of getRaiseAttr1(), which still leads to an uncaught css::uno::RuntimeException. Change-Id: I4a8ec09c270864ac4de246d7e8d1f923198236b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166585 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-02riscv64 bridge: replace some preprocessor directives to macros for debuggingSakura286
Change-Id: Ic53d4a462e12e8448b14e750c4ef2824385b8f28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165502 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-28riscv64 bridge: replace tab to space in call.sSakura286
Change-Id: I357f400050444336e26e73e1099b4b8ab9e8bdd1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165454 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-03-28riscv64 bridge: switch CRLF to LF in abi.cxx/hxxSakura286
Change-Id: I810f2681f61336eb823ab1eed89389d18b95dc75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165452 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-22Make msvc_raiseException explicitly [[noreturn]]Stephan Bergmann
The comments at <https://gerrit.libreoffice.org/c/core/+/165113/1#message-a76a16ede60a817426763c1c2c2090f23ae141e0> "framework: MenuBarManager: fix WNT crash if queryDispatch() throws" suggest that it was observed returning normally, and running into the > // is here for dummy > return typelib_TypeClass_VOID; in cpp2uno_call. Change-Id: I792a9eb82ef9e737aa69dc651b9a072871c0756b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165152 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-23Update IwyuFilter in bridgesGabor Kelemen
after commit 4b0c46dc61df243cda94f4a0af8946e076d1af54 Change-Id: If7c1d2a2b0d459271c0835f8fcdf084aa3482990 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163719 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
2024-02-21ofz#66731 Crash in com::sun::star::uno::BaseReference::iqueryCaolán McNamara
since commit f93ae0455c4d515be1ca663725a6e58d64a7e393 Date: Sat Feb 3 18:03:45 2024 +0100 Check bridges with IWYU presumably not using the _LIBCPPABI_VERSION branch move the _GLIBCXX_CDTOR_CALLABI fallback define to where its used while I'm at it, that too seems to be from cxxabi.h Change-Id: I2ead7207e3bcf24d3b120d22ae7f80e8f0a3216a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163672 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-12Fix IwyuFilter in bridgesGabor Kelemen
after commit b3fa6e6e65031f92d7f13b44f8422fe4aa07e2f9 Change-Id: I79e99d13d982f2190473904db4d63886c479b4f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163167 Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
2024-02-09Fix missing includesStephan Bergmann
...after f93ae0455c4d515be1ca663725a6e58d64a7e393 "Check bridges with IWYU" Change-Id: I01ca7b015cb9f4fc1dbff099c52e8240e1517270 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163126 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-02-08Check bridges with IWYUGabor Kelemen
Only the parts tha build on x64 arch See tdf#42949 for motivation Change-Id: Ifa3c5107887f5ab7837beee83d9603e8c883a7a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162961 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-01-28ofz: MemorySanitizer: extend use-of-uninitialized-value bridge workaroundCaolán McNamara
Change-Id: I84f458b540e2e43cb3b4a06f4353e37ee2b7da2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162646 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-26(riscv64) Fix Java bridgetest failureSakura286
* Refactor the code related to struct processing. Fix Java bridge- test failure. Fixed test list: * bridgetest-javaserver * [CUT] smoketest * [JUT] forms_unoapi_1 * [JUT] forms_unoapi_2 * [JUT] forms_unoapi_3 * [JUT] forms_unoapi_4 * Clean higher bit to prevent compiler generate wrong code when pyuno calls functions through UNO environment. This fixes some weired uitest failure. * Reorder the datatype list. Optimize the inserting args section in uno2cpp.cxx. * Remove some unused code. Change-Id: I74330126d31d847485b1d81fc34376b1d020f886 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160970 Tested-by: Jenkins Tested-by: René Engelhard <rene@debian.org> Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-21ofz: MemorySanitizer: use-of-uninitialized-valueCaolán McNamara
WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x2e4597d in TreatDoubleError /src/libreoffice/sc/source/core/inc/interpre.hxx:1146:10 #1 0x2e4597d in ScInterpreter::PushDouble(double) /src/libreoffice/sc/source/core/tool/interpr4.cxx:1806:5 #2 0x2e83755 in ScInterpreter::ScExternal() /src/libreoffice/sc/source/core/tool/interpr4.cxx:3126:17 #3 0x2e94a38 in ScInterpreter::Interpret() /src/libreoffice/sc/source/core/tool/interpr4.cxx:4487:43 #4 0x27296ad in ScFormulaCell::InterpretTail(ScInterpreterContext&, ScFormulaCell::ScInterpretTailParameter) /src/libreoffice/sc/source/core/data/formulacell.cxx:1946:23 #5 0x2722f87 in ScFormulaCell::Interpret(int, int) /src/libreoffice/sc/source/core/data/formulacell.cxx:1619:13 #6 0x1e1c80f in operator() /src/libreoffice/sc/source/core/data/column.cxx:2808:16 #7 0x1e1c80f in EachElem<mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell, mdds::mtv::delayed_delete_vector>, std::__1::__wrap_iter<ScFormulaCell **>, mdds::detail::mtv::iterator_value_node<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>, unsigned long>, (anonymous namespace)::CalcAllHandler> /src/libreoffice/sc/inc/mtvfunctions.hxx:130:9 #8 0x1e1c80f in ProcessElements1<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell, mdds::mtv::delayed_delete_vector>, (anonymous namespace)::CalcAllHandler, sc::FuncElseNoOp<unsigned long, bool> > /src/libreoffice/sc/inc/mtvfunctions.hxx:330:9 Uninitialized value was stored to memory at #0 0x2fdee53 in operator>>=<double> /src/libreoffice/sc/source/core/tool/rangeseq.cxx:0:14 #1 0x2fdee53 in ScApiTypeConversion::ConvertAnyToDouble(double&, com::sun::star::uno::TypeClass&, com::sun::star::uno::Any const&) /src/libreoffice/sc/source/core/tool/rangeseq.cxx:347:18 #2 0x2b1e9d4 in ScUnoAddInCall::SetResult(com::sun::star::uno::Any const&) /src/libreoffice/sc/source/core/tool/addincol.cxx:1583:17 #3 0x2b1d84f in ScUnoAddInCall::ExecuteCallWithArgs(com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /src/libreoffice/sc/source/core/tool/addincol.cxx:1541:9 #4 0x2b1c2ee in ScUnoAddInCall::ExecuteCall() /src/libreoffice/sc/source/core/tool/addincol.cxx:1495:9 #5 0x2e81a4b in ScInterpreter::ScExternal() /src/libreoffice/sc/source/core/tool/interpr4.cxx:3065:19 #6 0x2e94a38 in ScInterpreter::Interpret() /src/libreoffice/sc/source/core/tool/interpr4.cxx:4487:43 Uninitialized value was stored to memory at #0 0x2b1daec in swap<void *> /usr/local/include/c++/v1/__utility/swap.h:37:7 #1 0x2b1daec in operator= /src/libreoffice/include/com/sun/star/uno/Any.hxx:153:5 #2 0x2b1daec in ScUnoAddInCall::ExecuteCallWithArgs(com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /src/libreoffice/sc/source/core/tool/addincol.cxx:1518:14 #3 0x2b1c2ee in ScUnoAddInCall::ExecuteCall() /src/libreoffice/sc/source/core/tool/addincol.cxx:1495:9 #4 0x2e81a4b in ScInterpreter::ScExternal() /src/libreoffice/sc/source/core/tool/interpr4.cxx:3065:19 #5 0x2e94a38 in ScInterpreter::Interpret() /src/libreoffice/sc/source/core/tool/interpr4.cxx:4487:43 Uninitialized value was stored to memory at #0 0xc49bb64 in cppu::_copyConstructAnyFromData(_uno_Any*, void*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*), _uno_Mapping*) /src/libreoffice/cppu/source/uno/copy.hxx:178:49 #1 0xc497abd in cppu::_copyConstructAny(_uno_Any*, void*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*), _uno_Mapping*) /src/libreoffice/cppu/source/uno/copy.hxx:288:13 #2 0xc499443 in uno_any_constructAndConvert /src/libreoffice/cppu/source/uno/any.cxx:120:9 #3 0x174d263f in stoc_corefl::(anonymous namespace)::IdlInterfaceMethodImpl::invoke(com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /src/libreoffice/stoc/source/corereflection/criface.cxx:633:13 #4 0x174d5935 in non-virtual thunk to stoc_corefl::(anonymous namespace)::IdlInterfaceMethodImpl::invoke(com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /src/libreoffice/stoc/source/corereflection/criface.cxx:0 #5 0x2b1d5ce in ScUnoAddInCall::ExecuteCallWithArgs(com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /src/libreoffice/sc/source/core/tool/addincol.cxx:1518:27 #6 0x2b1c2ee in ScUnoAddInCall::ExecuteCall() /src/libreoffice/sc/source/core/tool/addincol.cxx:1495:9 #7 0x2e81a4b in ScInterpreter::ScExternal() /src/libreoffice/sc/source/core/tool/interpr4.cxx:3065:19 #8 0x2e94a38 in ScInterpreter::Interpret() /src/libreoffice/sc/source/core/tool/interpr4.cxx:4487:43 Uninitialized value was stored to memory at #0 0xcd10714 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) /src/libreoffice/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:157:51 #1 0xcd0cd78 in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void*, void**, _uno_Any**) /src/libreoffice/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233:13 #2 0xcd0a9fa in unoInterfaceProxyDispatch /src/libreoffice/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:0 #3 0x174d1f01 in stoc_corefl::(anonymous namespace)::IdlInterfaceMethodImpl::invoke(com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /src/libreoffice/stoc/source/corereflection/criface.cxx:590:9 #4 0x174d5935 in non-virtual thunk to stoc_corefl::(anonymous namespace)::IdlInterfaceMethodImpl::invoke(com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /src/libreoffice/stoc/source/corereflection/criface.cxx:0 #5 0x2b1d5ce in ScUnoAddInCall::ExecuteCallWithArgs(com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /src/libreoffice/sc/source/core/tool/addincol.cxx:1518:27 #6 0x2b1c2ee in ScUnoAddInCall::ExecuteCall() /src/libreoffice/sc/source/core/tool/addincol.cxx:1495:9 #7 0x2e81a4b in ScInterpreter::ScExternal() /src/libreoffice/sc/source/core/tool/interpr4.cxx:3065:19 #8 0x2e94a38 in ScInterpreter::Interpret() /src/libreoffice/sc/source/core/tool/interpr4.cxx:4487:43 Uninitialized value was created by an allocation of 'data' in the stack frame of function '_ZN4gcc317callVirtualMethodEPvjS0_P33_typelib_TypeDescriptionReferencebPmjS3_Pd' #0 0xcd0f1d0 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) /src/libreoffice/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:50 The double really comes from AnalysisAddIn::getConvert and when adding code to switch off it there and msan is happy before it returns that it is initialized, the problem arises when extracting that return value in the bridge code. Its curious that this only appears now when we've been running msan for years and only for double (so far) and not the other types. Change-Id: I8f381a9faf4fe9d4a02b77b241ab33de8eb3bce2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162348 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-17merge float fix from gcc3_linux_x86-64 to gcc3_macosx_x86-64Caolán McNamara
presumably we need the same fix there as done with: commit 3bcc14b4e2b226f97e937ca7a152218f8276ee39 Author: Stephan Bergmann <sbergman@redhat.com> Date: Thu Aug 3 13:21:44 2023 +0200 Fix handling of float vs. double values Change-Id: I7d6420dc954cdc320c9478172878e2a272ab2745 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162193 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-11-20Extended loplugin:ostr: bridgesStephan Bergmann
Change-Id: I8eefb64e75933ea9a4fbadb501182fc61bbf11b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159727 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-09enable unchecked lint for our java codeNoel Grandin
and annotate where necessary, mostly just suppressing the warnings Change-Id: I8e39d797cde6c7c3f4e3e1bd93a128965ecec81d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159205 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-09-12bridge/powerpc64: fix integer ABIDan Horák
The ABI document for PowerPC64 specifies that integer values shorter than a doubleword are sign or zero extended as necessary. Until now the smaller values were treated as unsigned values and only zero-extended. Handling of signed values was incorrect. Change-Id: Icbbe8fc8d4facfa6d1b3252c99ec2d8c2552d9f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156847 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-09-12bridge: modernize printf debugging in powerpc64Dan Horák
Use correct types and also typecasts to avoid compiler warnings. Change-Id: I3b58ec6a4be54ecd8bc07a7febbaf721eba9b945 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156846 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
generated by cgit (git 2.34.1) at 2024-12-25 21:00:42 +0000