• Stephan Bergmann's avatar
    SAL_DLLPUBLIC_RTTI for proper RTTI visibility for LLVM · b4f6b26b
    Stephan Bergmann yazdı
    The Itanium C++ ABI mandates that for a unique (complete) C++ type a single
    unique symbol for the type's RTTI name is used across a process's dynamic
    objects (so type equivalence can be determined via pointer comparison on the
    RTTI names).
    
    GCC nowadays deviates from that, using strcmp to determine equivalence, so it is
    resilient to RTTI names being bound locally within dynamic objects (which has
    performance benefits, but also makes it impossible to have unrelated types that
    happen to have the same name "encapsulated" in individual dynamic objects---
    whether or not that would violate the ODR would be open to interpretation of how
    dynamic objects fit into the C++ Standard).
    
    LLVM sticks to the Itanium ABI, which becomes notable in at least two places:
    
    For one, libc++abi's __dynamic_cast uses strict checking.  It still has a
    _LIBCXX_DYNAMIC_FALLBACK for now that additionally uses strcmp checking and
    syslogs visibility violations.  Mac OS X uses libc++abi with
    _LIBCXX_DYNAMIC_FALLBACK enabled, and running LO routinely logs dynamic_cast
    errors to the Console there.
    
    For another, RTTI-based UBSan checks unconditionally only use strict checking
    (cf. isDerivedFromAtOffset in lib/ubsan/ubsan_type_hash.cc).  This causes false
    positives from Clang -fsanitize=function and -fsanitize=vptr even on Linux not
    using libc++abi.
    
    Therefore, introduce SAL_DLLPUBLIC_RTTI to mark types for which RTTI needs to
    have default visibility under the Itanium/LLVM semantics.  There is
    unfortunately no way to mark only the (implicitly generated) RTTI symbols for
    default visibility, but at least with the cases where SAL_DLLPUBLIC_RTTI is used
    for now that is no real problem---any class type marked SAL_DLLPUBLIC_RTTI only
    has inline (covered by -fvisibility-inlines-hidden) or undefined pure virtual
    functions.  It appears that even the vtables of those classes remain hidden, at
    least with Mach-O on Mac OS X.  (That also means there is no need for a
    SAL_DLLPRIVATE_RTTI marker analoguous to the---also superfluous in retrospect---
    CPPU_GCC_DLLPRIVATE one.)
    
    Nevertheless, the number of exported symbols of course increases when
    SAL_DLLPUBLIC_RTTI is "active."  For a full-blown --enable-dbgutil build on Mac
    OS X,
    
      find instdir/LibreOffice.app/Contents -name \*.dylib\* -exec nm -gU {} \; \
        wc -l
    
    increased from 125541 to 139239.  For Linux, an option might be to "activate"
    SAL_DLLPUBLIC_RTTI only for __clang__ plus !ENABLE_RUNTIME_OPTIMIZATIONS.
    
    The set of types marked SAL_DLLPUBLIC_RTTI with this patch (wholesale cppumaker-
    generated UNO enum, struct, and interface types; plus some IEmbeddedHelper and
    IUndoManager) is chosen so that a full "make check" on Mac OS X no longer
    syslogs any dynamic_cast errors to the Console.
    
    Change-Id: I42fa6ec01c2503ec24bcd9c0518abb112afa3235
    b4f6b26b
embeddedobjectcontainer.hxx 11.1 KB