dynamic_cast form pointers not working with clang ndk 18, 19, 20 on arm64

[UVCAD]

The issue is reproduced with OCCT code base:
https://tracker.dev.opencascade.org/view.php?id=30937

Code snippet as below:
TDF_Attribute* aNSA = new TNaming_NamedShape();
TNaming_NamedShape* aNS = dynamic_cast<TNaming_NamedShape*>(aNSA);
if(!aNS )
{
std::cout << "Serious bug occured"; // bug here
}

Above code works with armv7, and it's just not working on arm64-v8a
after moving the inline destruction to cpp file, it works.

This issue is very similar to: #519
I'm not sure it's the same bug.

[enh-google]

have you followed the steps on that bug to use readelf to check for typeinfo and key functions in all the libraries involved?

[UVCAD]

Yes, i tried that. I found that when the destruction are moved to cpp file, the typeinfo is GLOBAL, otherwise, it's WEAK.

[UVCAD]

My environment is on windows-x86-64, i'm curious why it works on armv7.

[DanAlbert]

after moving the inline destruction to cpp file, it works.

This is expected behavior.

[UVCAD]

do you mean destructor can't be inline? it's definitely a bug of compiler. Why close this???

[DanAlbert]

It's not a compiler bug. This is how the C++ ABI is defined. Your classes need a key function.

https://android.googlesource.com/platform/ndk/+/master/docs/user/common_problems.md#rtti_exceptions-not-working-across-library-boundaries

[UVCAD]

1. My question is that why it works for ARMV7, not working for ARMV8.

2. Also, there is at least one key function defined as below:
   class TNaming_NamedShape:
   Standard_EXPORT virtual Handle(TDF_Attribute) BackupCopy() const Standard_OVERRIDE;

[DanAlbert]

The only information I have to go on is what you provided. Can you provide instructions to reproduce your issue?

My question is that why it works for ARMV7, not working for ARMV8.

armv8 as in arm64, or 32-bit Arm with -march=armv8? The former is still linked with bfd, so if this is a bug it could be a bug in bfd. If that's the case, bfd is unlikely to be getting any updates, so the fix will be switching to lld (if you're using Windows, that's not great until r20).

[UVCAD]

CMake instruction for armv7
set (ANDROID_ABI armeabi-v7a)
set (ANDROID_PLATFORM 21)
set (ANDROID_STL c++_shared)

CMake instruction for armv8;
set (ANDROID_ABI arm64-v8a)
set (ANDROID_PLATFORM 21)
set (ANDROID_STL c++_shared)

Host machine is windows and ndk version r18,r19,r20 have the same issue.

[DanAlbert]

That's not sufficient. We need the code that has the failing behavior.

[DanAlbert]

Code as in a failing test case, I see your project and the snippet, but I don't know how they fit together.

Did you try switching from bfd to lld or gold?

[UVCAD]

it's rather complex to reproduce the issue since it's a system project. It's related to the geometry visualization, geometry modeling. So i just can provide the code snippet of the problem.
I use the cmake default option without trying to switch the linker. Do you teach me how to switch the linker in cmake option?

[UVCAD]

I find the same issue reproduced on MAC.

[UVCAD]

The default linker is:
On Windows:
CMAKE_LINKER:FILEPATH=D:/AndroidSDK/android-ndk-r19c/toolchains/llvm/prebuilt/windows-x86_64/bin/arm-linux-androideabi-ld.exe

On MAC
CMAKE_LINKER:FILEPATH=/software/AndroidSDK/ndk/20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android-ld

Could you tell how to switch the linker in cmake?

[DanAlbert]

Add -fuse-ld=gold (or -fuse-ld=lld) to your link flags. Probably by appending them to CMAKE_C_FLAGS, but it sort of depends on how your project configures linker flags.

[UVCAD]

I have tried gold linker, it makes no difference.
I think the problem is related to libc++_shared.so which should be built with gold linker too. because the dynamic_cast<> operator is in stl. Will you provide a libc++_shared.so for me to test this issue?

[DanAlbert]

Renamed as .txt because github won't let me upload a .so, but here you are: libc++_shared.so.txt

It's built from the r20 branch, so it should work with what you have.

[DanAlbert]

(reopening while we continue investigating)

[UVCAD]

It's no lucky to make it work even with your provided libc++_shared.so.
I replaced the linker ld.exe with ld.gold.exe directly to be sure gold linker is used.

[UVCAD]

Looking forward this to be fixed in R20. Because Google Play don't allow to submit APP without 64 bit APK since August 1st, 2019, this issue blocked our APP to Google Play. Do you think it's possible to fix it in R20 branch? Thanks for your hard working in advance.

[DanAlbert]

Unfortunately there's very little we can do to fix this if we can't reproduce the issue. Our guesses so far have been wrong (or, if the original guess that it's a problem of a missing key function, it's not confirmed, but it isn't for at least TNaming_NamedShape), and without knowing what's wrong we can't fix it.

The bright side is that it does seem you have a workaround:

I found that when the destruction are moved to cpp file, the typeinfo is GLOBAL, otherwise, it's WEAK.

[UVCAD]

I have being working on this blocking issue for several months. I'm really really so frustrated.
I have no much experience on such system project like compiler and linker. :-(
There are many code related to this in OCCT, it's a huge task to workaround this.
I have a thought in my mind. I need you help.
Could you please help me build a NDK package special for arm64-v8a?
The package should have the the similar configuration with armeabi-v7a.
The default linker to gold, default c++ typeinfo compare option _LIBCXX_DYNAMIC_FALLBACK which compare string as fallback.
I appreciate you help.

[DanAlbert]

Closing for lack of info. lmk if you're able to reduce a test case so we can investigate.