[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