[llvm-bugs] [Bug 45258] New: Type id miss match when std::any object passed to shared library on AARCH64 Linux

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Mar 19 16:58:33 PDT 2020


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

            Bug ID: 45258
           Summary: Type id miss match when std::any object passed to
                    shared library on AARCH64 Linux
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: yschandra at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

Created attachment 23264
  --> https://bugs.llvm.org/attachment.cgi?id=23264&action=edit
Example implementation

When RTTI is disabled libc++ has a implementation of using address of static
member for each type
(https://github.com/llvm/llvm-project/blob/master/libcxx/include/any#L154-L161),
this particular method fails on AARCH64 Linux (-target aarch64-linux-android)
when a std::any object passed by reference to a method in dynamic library it
raises bad_any_cast() exception even though type did not change. The same works
as expected on x86_64 Linux (-target x86_64-linux-android). Both are same
version of clang and libc++. 

This issue is seen with 9.0.0, 10.0.0rc3, trunk (11.0.0) clang & libc++. 

To demonstrate the problem I have a small example implemented which reproduces
the issue without libc++.

On aarch64-linux-android this example produces output

fallback type before calling function pointer 0x40002c3b4504
fallback type in function pointer             0xaaaacc30a5d4

On x86_64-linux-android this example produces output

fallback type before calling function pointer 0x58d4496a155c
fallback type in function pointer             0x58d4496a155c

To me it appears that on AARCH64 there are 2 instances of static member one in
shared library and one in main executable, leading to this issue.

Any help is appreciated on this.

-- 
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/20200319/f4f59783/attachment.html>


More information about the llvm-bugs mailing list