...same as 5ba3d1740b03efa394b2d2bf34fb8a8d3db2331d "Clean up declaration of
__cxa_get_globals" plus c17f01753ce94e9f57d6e4a2763152240fbcd50a "...and
similarly for __cxa_allocate_exception and __cxa_throw."
Change-Id: I02361cfca260577ce13fb634b5637938daf0283d
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
