Fix macOS ARM64 RTTI generation

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>

0 files changed, 0 insertions, 0 deletions