Skip to content
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

Closed
DanAlbert opened this issue Oct 3, 2019 · 1 comment
Closed

[BUG] unwinder symbols are no longer hidden with ndk-build #1092

DanAlbert opened this issue Oct 3, 2019 · 1 comment
Assignees
Labels
Milestone

Comments

@DanAlbert
Copy link
Member

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo.cpp
LOCAL_CPPFLAGS := -fexceptions -frtti
include $(BUILD_SHARED_LIBRARY)
APP_STL := c++_static
void foo() {
    throw 42;
}
$ 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 to LOCAL_LDFLAGS fixes this, so this was caused by changing libgcc.a to be a version script (r19, if memory serves).

@DanAlbert
Copy link
Member Author

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 --exclude-libs was still working fine with libunwind, the unwind symbols remained hidden in 32-bit arm outputs.

Still, I've fixed this for the other ABIs to defend against future ABI breaks: https://android-review.googlesource.com/c/platform/ndk/+/1133109

disigma pushed a commit to wimal-build/ndk that referenced this issue Oct 4, 2019
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
disigma pushed a commit to wimal-build/ndk that referenced this issue Oct 5, 2019
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant