[llvm-bugs] [Bug 33542] New: std::type_index equality broken across shared library boundaries on Linux

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=33542

            Bug ID: 33542
           Summary: std::type_index equality broken across shared library
                    boundaries on Linux
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: wenzel.jakob at epfl.ch
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org

Dear all,

I'm consistently running into issues where Clang does not preserve
std::type_index equality across shared library boundaries.

I've created a minimal failing example (https://github.com/wjakob/clang_issue)
with the following structure:

1. A shared library "shared.so" exports a simple type named "Test"

    #define EXPORT __attribute__ ((visibility("default")))

    class EXPORT Test {
    public:
        Test();
    };

2. Two shared libraries mod1.so and mod2.so export the following function

   EXPORT std::type_index get_mod[1/2]() { return typeid(Test); }

3. An executable "main" loads both mod1.so and mod2.so and checks if get_mod1()
== get_mod2().


On my machine (Linux/x86_64, Clang trunk), I observe different results
depending on the C++ standard library being used:

- libstdc++ states that the std::type_index return values agree.

- libc++ states that the std::type_index return values DO NOT agree. :(

My hunch is that Clang never exports the typeid data structure despite the
visibility("default") annotation, which seems to be confirmed by "nm":

$ nm shared.so | grep Test | c++filt                                           
                                                             00000000000006a0 T
Test::Test()
00000000000006a0 T Test::Test()
$

Potentially libstdc++ then compares type mangled type names, whereas libc++ is
more strict and requires the underlying typeid data structure to be at the same
address in memory.

Interestingly, this seems to be a Linux-specific inconsistency. The issue does
not appear on Mac OS (again, using Clang and libc++).

This has unfortunately become a serious issue in a modular software platform
that is currently in development (dynamic_casts stop working, etc.). I'm
wondering if

1. This is a bug in Clang or libc++? If so, how can it be fixed?

2. Is there a magic incantation/command line flag that is missing on Linux to
enable a consistent behavior across platforms?

Thank you and best regards,
Wenzel

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170621/481bc6c0/attachment-0001.html>