Panic=abort as a target option? #36647
Comments
|
A concept of targets without unwinding support would not only be useful for embedded programming but also for GPU-ish targets. |
|
This seems reasonable to me. The current default is set here but we could make that an option and instead punt the default to the target spec. |
|
I'll give this a try. |
japaric
pushed a commit
to japaric/rust
that referenced
this issue
Sep 28, 2016
Now a target can define its panic strategy in its specification. If a user doesn't specify a panic strategy via the command line, i.e. '-C panic', then the compiler will use the panic strategy defined by the target specification. Custom targets can pick their panic strategy via the "panic-strategy" field of their target specification JSON file. If omitted in the specification, the strategy defaults to "unwind". closes rust-lang#36647
|
Fix in #36794 |
sophiajt
pushed a commit
to sophiajt/rust
that referenced
this issue
Sep 29, 2016
add a panic-strategy field to the target specification Now a target can define its panic strategy in its specification. If a user doesn't specify a panic strategy via the command line, i.e. '-C panic', then the compiler will use the panic strategy defined by the target specification. Custom targets can pick their panic strategy via the "panic-strategy" field of their target specification JSON file. If omitted in the specification, the strategy defaults to "unwind". closes rust-lang#36647 --- I checked that compiling an executable for a custom target with "panic-strategy" set to "abort" doesn't need the "eh_personality" lang item and also that standard crates compiled for that custom target didn't contained undefined symbols to _Unwind_Resume. But this needs an actual unit test, any suggestion on how to test this? Most of the noise in the diff is due to moving `PanicStrategy` from the `rustc` to the `rustc_back` crate. r? @alexcrichton cc @phil-opp
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Let's assume a target with no unwinding support (e.g. a small system on a chip). RFC 1513 added a
-C panic=strategyflag and a cargo profile option for disabling the unwinding machinery. However, even with those options, we still need dummy implementations foreh_personalityand_Unwind_Resume.The reason is that the cross-compiled sysroot (e.g. via xargo) still contains references to those functions. We can avoid this by setting
RUSTFLAGSto-C panic=abortwhen invokingxargo. This way, the sysroot is created without unwinding. This solution works, but feels a bit hacky.We could solve this problem in an easier way if we added a option for
panic=abortin the target json. Then we could express targets without unwinding support and xargo would automatically compile the sysroot correctly.The text was updated successfully, but these errors were encountered: