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
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
It seems to be the type_info most commonly looked up dynamically, even
the only one in an initial test. I think it is a good idea to avoid
dlsym() if possible.
Change-Id: I0379c534e10efefafdd253ee651f6c74e4aa47d5
Done with a perl regex:
s/OUString\s*\(\s*RTL_CONSTASCII_USTRINGPARAM\s*\((\s*"[^")]*?"\s*)\)\s*\)/OUString\($1\)/gms
Change-Id: Idf28320817cdcbea6d0f7ec06a9bf51bd2c3b3ec
Reviewed-on: https://gerrit.libreoffice.org/2832
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
Reduce excessive copy-pasting
Remove bridges for C50 and C52 compilers which aren't in configure any
more
Prevent LTO from being used in the bridges module because it causes
crashes
Change-Id: I7ff85c2e8d6ff89c5acd48aea415e0960b3ef812
Reviewed-on: https://gerrit.libreoffice.org/2765
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
As the inline asm statement stores parameters into r0-r3 we need to
include those registers in the clobber list. Clang happened to store
pMethod in r2 as input to the asm snippet.
iOS uses the basic calling convention, but __ARM_EABI__ is not defined
so amend some ifdefs.
Change-Id: If3d66c5f3baa4dfa13f82a2b5c2ef1ab559ce31b
Split uno2cpp.cxx and cpp2uno.cxx into separate files for the emulator
(i386) and device (ARM). Much cleaner like that.
Try harder to get the ARM stuff to actually work.
Add the rtti.h and unwind-cxx.h files from libcppabi as such instead
of cherry-picking stuff from them.
Change-Id: Ia238a9ce048116ad796dfb168fd4e5d3b9712ad5
The asm code loads values into parameter-passing registers r0-r3.
(That is one of the very purposes of the asm snippet.) We need to tell
the compiler that. The compiler does not analyze the asm snippet and
has no idea by itself what it does.
Otherwise the compiler might well put one of the input values to the
asm snippet, like the "pmethod" (the value of the pMethod variable)
into one of those registers, so that when that value then is used in
the asm snippet, *after* r0-r3 have already been modified, it
obviously is totally unrelated to pMethod any more, and the result is
that the code jumps into hyperspace.
Apparently this has worked purely by luck, or thanks to GCC
conservatively avoiding using the r0-r3 parameter-passing registers in
this way. The problem was noticed when using the same code with Clang.
The above analysis tentatively confirmed by Caolán and Jani Monoses,
who wrote the code.
Change-Id: I3018c2e2ccb83e7a71144425fa404ad28bb955d6
This changes all generated API headers (.hpp and .hdl) to use a
namespace alias 'css' instead of the pointlessly long com::sun::star
Makes the change in cppumaker & associated tools, adds a global
namespace alias definition in sal/types.h, and removes a kiloton
of local, now pointless-to-harmful versions of that alias from all
over the code.
Change-Id: Ice5a644a6b971a981f01dc0589d48f5add31cc0f
Use it in the cases where I yesterday changed SAL_DLLPUBLIC_EXPORT to
JNIEXPORT. It turns out that on Linux JNIEXPORT does not enforce
"default" visibility, but expands to empty.
Change-Id: I033b3cf538715fb596e965e17f3da12fb987df63
Now with DISABLE_DYNLOADING, SAL_DLLPUBLIC_EXPORT actually means
hidden visibilty. Which is OK in general as with a single DSO (or a
single executable, for iOS), none of our "normal" entry points need to
be visible froom the outside.
So for the JNI entry points use JNIEXPORT. On "normal" platforms it
should be equivalent to SAL_DLLPUBLIC_EXPORT.
Change-Id: Iad634950e635ac03a0e90cae6d00afd9fb4eeb64
Putting the privateSnippetExecutor() assembly code as inline asm
inside an otherwise empty C++ function helps, for some reason.
Use the actual _Unwnd_Exception and __cxa_exception definitions as
used by Apple (from opensource.apple.com libunwind and libcppabi
sources) instead of guessing.
Change-Id: I1ef22a9c0c664d3a357b9a6474406141f53cc490
