-
Notifications
You must be signed in to change notification settings - Fork 254
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
exception handling doesn't work with static executables #593
Comments
So exceptions not work with libc++ static ? |
re: no stack traces in logcat, try gdbclient? |
The patch above fixes arm32. The other architectures (arm64 at least, I haven't gotten to testing the Intel arches yet, but the fix is likely the same) are broken because Clang doesn't automatically pass This actually isn't unique to libc++. Exceptions don't work for any STL with static executables because of this. I'm trying to dig into why Clang doesn't do that and get it fixed, but that will require a clang update. Until then, you can use exceptions in static executables by adding |
__exidx_start and __exidx_end are not actual values to be read, just symbols placed before and after .ARM.exidx. The default linker script for ARM static executables includes these lines: __exidx_start = .; .ARM.exidx : { *(.ARM.exidx*) } __exidx_end = .; http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474c/BABEHEDA.html Test: used __gnu_Unwind_Find_exidx in a static executable and showed non-bogus values Test: verified that this fixes #593 in the NDK Bug: android/ndk#593 Change-Id: Ib35a4b6c82920666ae8a45aa0a2d43e458699b51
I'm encountering this problem too (using zxing which heavily uses exceptions for not detecting barcodes, yuck), looking at that link above, do you know when or in what NDK the fix will be released? |
The milestone is accurate. This is fixed in r17, but not necessarily in beta 1. |
The arm32 fix is now in r17 (will be in beta 1 since we're respinning that for a gradle workaround). The --eh-frame-hdr issue has a patch up for clang (https://reviews.llvm.org/D43203), but that won't land in the NDK until at least r18. We can still do a bit more work for r17 to add |
https://android-review.googlesource.com/c/platform/ndk/+/618577 hoists this into the build systems until we get a clang with the fix. |
r17 beta 1 is being respun again, so this will be in after all. I'll leave the bug open to track the clang fix, but I'm moving this off the r17 milestone since we've done as much as we can for this release. |
Change is submitted upstream. Over to @stephenhines to get the change into the next clang update. |
Fixed in r17 after all since we needed one last clang respin. |
Clang doesn't pass this automatically for static executables for some reason, and libgcc can't unwind without a .eh_frame_hdr section. Also move the test to libc++ since gnustl is going away soon. Test: ./run_tests.py --filter static-executable-exceptions Bug: http://b/24468267 Bug: http://b/30101473 Bug: http://b/72512648 Bug: android/ndk#593 Change-Id: I153dfee4d22082560833517f1ee575742da21e21 (cherry picked from commit 2f7aa277079f13e431f355c33ccf1ab601d3e947)
Unfortunately static executables with libc++ will require API > 26 to avoid libandroid_support. Fortunately this doesn't actually cause any issues except in the case of having a static executable in the same project as other non-static executable modules. Test: ./run_tests.py Bug: http://b/24507500 Bug: android/ndk#593 Change-Id: I925dac426a41326c76bddec691ba8ce227ba5370 (cherry picked from commit d0dd54a20855dcb9cfdcda2c129edf1e4d2f42bb)
Better than making all the users do it themselves. We can revert this once we get a clang with https://reviews.llvm.org/D43203. Test: ./checkbuild.py && ./run_tests.py Bug: android/ndk#593 Bug: http://b/72512648 Change-Id: I53791d53cfab8eefe004f8e278527c80f1fa1240 (cherry picked from commit c8558428d993000a68fe0e72815b2bb85f228438)
Test: ./checkbuild.py && ./run_tests.py Bug: android/ndk#593 Bug: http://b/72512648 Change-Id: I01df21b47da547efc6c8b029fc389423e9a63c23 (cherry picked from commit fa3562bbdad17357fb7fb01cb77ac546abfa99a2)
Test: ndk/checkbuild.py && ndk/run_tests.py Bug: android/ndk#593 Change-Id: Ifee3ce4bdf810e68f0012a978b520e4222607939 (cherry picked from commit eaf16d99504a191679b5ca97466ee7aeaecd9089)
@DanAlbert This is not fully fixed, at least for old platforms (tested with NDK r20, target platform v21), because the definition of Since statically linked libc is problematic, I have to backport this and pass I've tested it in a real machine running Android 9.0 and it fails at
Is this related to https://bugs.llvm.org/show_bug.cgi?id=21053? |
Then it sounds like you aren't using a static executable. Could you verify that? |
@DanAlbert My fault. I was testing the standalone toolchain with different project configurations and occasionally got confused by makefiles having different linker flags ( The previously mentioned problem still exists in the configuration with a single |
Yeah, go ahead and open a new bug if you find something. It's almost always a broken dependency in this situation. |
I find it a code generation issue, reported upstream. |
Thanks! I filed #1079 to track that on our side. |
__exidx_start and __exidx_end are not actual values to be read, just symbols placed before and after .ARM.exidx. The default linker script for ARM static executables includes these lines: __exidx_start = .; .ARM.exidx : { *(.ARM.exidx*) } __exidx_end = .; http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474c/BABEHEDA.html Test: used __gnu_Unwind_Find_exidx in a static executable and showed non-bogus values Test: verified that this fixes #593 in the NDK Bug: android/ndk#593 Change-Id: Ib35a4b6c82920666ae8a45aa0a2d43e458699b51
__exidx_start and __exidx_end are not actual values to be read, just symbols placed before and after .ARM.exidx. The default linker script for ARM static executables includes these lines: __exidx_start = .; .ARM.exidx : { *(.ARM.exidx*) } __exidx_end = .; http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474c/BABEHEDA.html Test: used __gnu_Unwind_Find_exidx in a static executable and showed non-bogus values Bug: android/ndk#593 Change-Id: Ib35a4b6c82920666ae8a45aa0a2d43e458699b51
Currently undiagnosed. Since it's a static executable, we don't get a stack trace in logcat.
The text was updated successfully, but these errors were encountered: