Apparently there was no problem in this after all. The reason it
seemed not to work earlier was because of the unwinding failure due to
the missing .cfi_startproc and .cfi_endproc thingies in helper.s
The hack in ucbhelper is now not needed after all.
Change-Id: If9fec5c502d4c9d0c44709ad9c2729f812e882e2
Helps a bit... Now, if I revert the hackish arm64 change to ucbhelper,
instead of "terminating with uncaught exception" I get "terminating
with unexpected exception";) But, at least with the stack correctly
unwound to BaseContent::execute(), I think. Actually of course I don't
really understand much of this.
Change-Id: Iacb4342414cb84f9db31f9a40c7a136cc5d191a6
Doesn't help though, throwing exceptions using __cxa_throw() and our
hand-crafted type_infos still doesn't work on arm64.
Change-Id: If6099e8696e6232c4b6d4bacd654d28419538e0f
It is the same as Linux@PowerPC 32-bit (cp -r gcc3_linux_powerpc gcc3_macosx_powerpc),
with differences applied:
* Use 13 FP registers and correct 'codeSnippetSize' (8*4 + 13*8 = 136).
* Use "frame pointer + 24", not "+8".
* Don't USE_DOUBLE_MMAP and 'sal_PtrDiff writetoexecdiff'.
* Don't use "__NO_FPRS__", OS X capable PowerPC machines all have FPRs.
* Use "rN"/"fN" syntax to avoid "Parameter syntax error" errors.
* Include sys/types.h, sys/malloc.h instead of malloc.h;
don't include string.h.
Change-Id: I5b251c65466af2a06bd309d3a7b1aaf26ac12656
Reviewed-on: https://gerrit.libreoffice.org/7072
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Unlike libstdc++.dylib, libc++abi.dylib no longer exports the type info for
std::type_info, but the layout of the __cxxabiv1::__*_type_info classes is
controlled by the Generic C++ ABI anyway, so consolidate to a single approach
that works across all versions.
Change-Id: Ic68f2386261bae4a4349ad646590cc15c768f04e
At least Clang trunk towards 3.4 now rejects incompatible declarations of the
same extern "C" function in different namespaces, so that trick of getting at
the function that is exported by libstdc++ but only rudimentarily if at all
exposed in cxxabi.h no longer worked.
TODO: This change should be reflected in any other bridges where it is relevant,
too.
Change-Id: Ie3ccbdb7d75cc98636d02c0435958532620724f2
... by removing obsolete OSL_ENSURE. nVtableCall was renamed to
nFunctionIndex and the same check is done a couple of lines above.
Change-Id: Id52b69adceb337049c50a599aefc718498d688c0
Apparently whoever did these didn't get the gcc docs and specified
every operand only as input, and then added volatile, explicit
initialization and what not until it worked. Specify output operands
correctly instead.
I couldn't verify all assembler variants, as I don't know them,
but the ones I don't know had at least some proper usage of output
operands, so I'll assume those are all correct.
Change-Id: I2910308b5e00cce8db756496df50ed26cfe35bb6
if the pCallStack variable is optimized out then any assumptions of the
method's inlined assembler about stack layout collapse. Adding a pseudo
dependency to the pCallStack variable solves that problem
(cherry picked from commit 254359b9ed96152091b8f7a74a3442cf6c553e04)
Conflicts:
bridges/source/cpp_uno/gcc3_freebsd_x86-64/uno2cpp.cxx
bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx
Change-Id: I5ba7713c2630bb3ecc4343632e796c38541bcd0e
(It causes linker errors, type_info destructor not found and a few
others. Possibly this is a bug in Apple's libc++abi?)
Change-Id: I50bc97c8e061ff47d4ff16f31d37cfe3b4f5a010
The type_info crack is even harder in the libc++ (with Clang, on OS X)
case, sigh. Punt for now and let's see what happens...
Change-Id: I17c3a4d9d933acfbf554649c9ec8b6fb5213f2f0
ceterum censeo: good old C-linkage interoperability would be much more robust,
reliable and easier to maintain compared to the current UNO-bridges approach
of emulating the behaviour of the individual compiler, linker, dylib, unwind, etc.
environments and thus being extremely platform specific. What an incredible waste
of energy for little (if any) gain. SCNR.
(cherry picked from commit c9fe5d026f2081d493a198a33cf3b1d558166965)
Conflicts:
bridges/source/cpp_uno/gcc3_freebsd_x86-64/call.s
Change-Id: I728bce449e8e56572f31b50fb1452d1c2f9d7fea
