-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
-C panic=abort doesn't generate EHABI information on arm #49867
Comments
Note the same actually applies to EH_FRAME info on x86-64, which iirc the Firefox profiler also uses on x86-64. More generally, it can be desirable to have unwind info even when panic doesn't unwind. |
For C/C++ code in Firefox we use The equivalent for x86-64 is It seems like having a compiler option to enable this would be good enough, since the behavior here mirrors what gcc does: only emit unwind info if needed for exceptions/unwinding. |
LLVM seems to turn on EHABI as default by https://reviews.llvm.org/D2627 (EnableARMEHABI is removed by this landing, but src/rustllvm/PassWrapper.cpp still has it) |
This may or may not be related to #45031, but I can prepare a patch like #40549 for the targets here. @makotokato do you know what targets are in use by Firefox and would need this treatment? |
Long ago (rust-lang#40549) we enabled the `uwtable` attribute on Windows by default (even with `-C panic=abort`) to allow unwinding binaries for [stack unwinding information][winstack]. It looks like this same issue is [plaguing][arm1] Gecko's Android platforms [as well][arm2]. This commit applies the same fix as rust-lang#40549 except that this time it's applied for all Android targets. Generating a `-C panic=abort` binary for `armv7-linux-androideabi` before this commit generated a number of `cantunwind` functions (detected with `readelf -u`) but after this commit they all list appropriate unwind information. Closes rust-lang#49867 [winstack]: https://bugzilla.mozilla.org/show_bug.cgi?id=1302078 [arm1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1453220 [arm2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1451741
rustc: Always emit `uwtable` on Android Long ago (#40549) we enabled the `uwtable` attribute on Windows by default (even with `-C panic=abort`) to allow unwinding binaries for [stack unwinding information][winstack]. It looks like this same issue is [plaguing][arm1] Gecko's Android platforms [as well][arm2]. This commit applies the same fix as #40549 except that this time it's applied for all Android targets. Generating a `-C panic=abort` binary for `armv7-linux-androideabi` before this commit generated a number of `cantunwind` functions (detected with `readelf -u`) but after this commit they all list appropriate unwind information. Closes #49867 [winstack]: https://bugzilla.mozilla.org/show_bug.cgi?id=1302078 [arm1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1453220 [arm2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1451741
Allow not emitting `uwtable` on Android `uwtable` is marked as required on Android, so it can't be disabled via `-C force-unwind-tables=no`. However, I found that the reason it's marked as required was to resolve a [backtrace issue in Gecko](rust-lang#49867), and I haven't find any other reasons that make it required ([yet](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Unwind.20tables.20are.20strictly.20required.20on.20Windows.20and.20Android)). Therefore, I assume it's safe to turn it off if a (nice) backtrace is not needed, and submit this PR to allow `-C force-unwind-tables=no` when targeting Android. Note that I haven't tested this change on Android as I don't have an Android environment for testing.
From https://bugzilla.mozilla.org/show_bug.cgi?id=1453220
Gecko profiler uses EHABI information to walk stack. But since rustc doesn't generate EHABI, it cannot walk stack on generated code by rust.
@glandium says, "-C panic=abort" causes that EHABI isn't emitted", so we need a option not to remove it (or don't remove EHABI even if -C panic=abort).
The text was updated successfully, but these errors were encountered: