-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] unwinder symbols are no longer hidden with ndk-build #1092
Comments
This isn't as problematic as I'd feared. The ABI that this causes issues on (arm32) was unaffected for the same reason that it's the one that usually has problems: it uses a different unwinder. Since libunwind was always being linked first and Still, I've fixed this for the other ABIs to defend against future ABI breaks: https://android-review.googlesource.com/c/platform/ndk/+/1133109 |
When we switched to using a linker script for libgcc in r19 we broke `-Wl,--exclude-libs,libgcc.a`, because `--exclude-libs` has no effect on the contents of linker scripts. As such, libgcc was not being hidden as expected. The good news is that on the one platform this causes the most trouble (Arm32, since it uses the LLVM unwinder for exception handling rather than libgcc) this didn't cause any issues. Since libunwind was linked first (and the `--exclude-libs` worked there, since the actual library was named), the libgcc unwind symbols did not end up in the output at all. So while this has not caused any issues, it is still a good idea for us to link libgcc hidden to guard against any future unwind ABI breaks. Test: Added a test that checks ndk-build output with readelf Bug: android/ndk#1092 Change-Id: I5c8203afd29f0b7b272a51aadfc1a5ca6cbd33e4
When we switched to using a linker script for libgcc in r19 we broke `-Wl,--exclude-libs,libgcc.a`, because `--exclude-libs` has no effect on the contents of linker scripts. As such, libgcc was not being hidden as expected. The good news is that on the one platform this causes the most trouble (Arm32, since it uses the LLVM unwinder for exception handling rather than libgcc) this didn't cause any issues. Since libunwind was linked first (and the `--exclude-libs` worked there, since the actual library was named), the libgcc unwind symbols did not end up in the output at all. So while this has not caused any issues, it is still a good idea for us to link libgcc hidden to guard against any future unwind ABI breaks. Test: Added a test that checks ndk-build output with readelf Bug: android/ndk#1092 Change-Id: I5c8203afd29f0b7b272a51aadfc1a5ca6cbd33e4 (cherry picked from commit b1d17d6)
APP_STL := c++_static
$ ndk-build -C foo APP_ABI=arm64-v8a -B V=1 (build output shows -Wl,--exclude-libs,libgcc.a) $ readelf -sW libs/arm64-v8a/libfoo.so| grep _Unwind (shows global visibility unwind symbols)
Adding
-Wl,--exclude-libs,libgcc_real.a
toLOCAL_LDFLAGS
fixes this, so this was caused by changing libgcc.a to be a version script (r19, if memory serves).The text was updated successfully, but these errors were encountered: