Match libunwind's EABI selection with libpanic_unwind #47571
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Thanks @FenrirWolf ! We'll rustle up a first-class review from @aturon or another great team member soon! |
shepmaster
added
the
S-waiting-on-review
kennytm
added
the
O-Arm
|
Review ping for you @aturon! |
|
@bors: r+ |
|
📌 Commit 01059b9 has been approved by |
kennytm
added
S-waiting-on-bors
Match libunwind's EABI selection with libpanic_unwind Currently, the `libunwind` crate will only select the ARM EABI if it is compiling for ARM/Linux or Android targets. `libpanic_unwind`, however, will choose the ARM EABI if the target arch is ARM and the OS is not iOS. This means that if one tries to enable unwinding for a non-standard ARM target (such as implementing a custom stdlib via Xargo, for example), then the two crates can potentially disagree about which EABI is being targeted. This PR makes `libunwind` use the [same logic](https://github.com/rust-lang/rust/blob/master/src/libpanic_unwind/gcc.rs#L139-L146) as `libpanic_unwind` when choosing the EABI. I noticed there are a few comments about certain functions only differing on Android or ARM/Linux, but I *think* that those differences apply to the ARM EABI in general. Let me know if I'm wrong about that.
|
☀️ Test successful - status-appveyor, status-travis |
Currently, the
libunwindcrate will only select the ARM EABI if it is compiling for ARM/Linux or Android targets.libpanic_unwind, however, will choose the ARM EABI if the target arch is ARM and the OS is not iOS. This means that if one tries to enable unwinding for a non-standard ARM target (such as implementing a custom stdlib via Xargo, for example), then the two crates can potentially disagree about which EABI is being targeted.This PR makes
libunwinduse the same logic aslibpanic_unwindwhen choosing the EABI.I noticed there are a few comments about certain functions only differing on Android or ARM/Linux, but I think that those differences apply to the ARM EABI in general. Let me know if I'm wrong about that.