Tracking Issue for "C-unwind ABI", RFC 2945

[nikomatsakis]

This is a tracking issue for the RFC "C-unwind ABI" (rust-lang/rfcs#2945).

The feature gate for the issue is #![feature(c_unwind)].

This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC
• Adjust behavior of panic extern "C" fn"
  • panic in a no-unwind function leads to not dropping local variables #123231
  • Make destructors on extern "C" frames to be executed #129582
• Adjust documentation
  • panic runtime and C-unwind documentation reference#1226
• Stabilization PR (see instructions on rustc-dev-guide)

Implementation notes

Major provisions in the RFC:

• Add a C-unwind ABI and system-unwind (I think), we may need more variants.
• For external functions with the C ABI, we already (I believe) add the "nounwind" LLVM attributes when we build them. We want to continue doing this.
• For external functions with the C-unwind ABI, we do not want any such attributes.
• For Rust functions defined with the C ABI, e.g., extern "C" fn foo() { ... }, we want to force them to abort if there is a panic. The MIR helper function should_abort_on_panic already exists and I think will modify the generated code to insert the required shims in such a case. They should also be marked as "nounwind" in LLVM, if they're not already.
• Rust functions with the "C-unwind" ABI should not abort on panic.
• Use ABI to guide the "nounwind" attribute on callsites as well.
• Write suitable codegen tests to check generated LLVM IR.

Unresolved Questions

None. The unresolved questions in the RFC were meant to be solved by future RFCs building on this one.

Implementation history

• Initial implementation: Implement RFC 2945: "C-unwind" ABI  #76570
• Additional work (removing #[unwind], adjusting panic handling): rustc: Fill out remaining parts of C-unwind ABI #86155

[cratelyn]

Hello! I would be interested in helping implement this RFC. 🙋

(cc: @aturon)

[nikomatsakis]

Hey @katie-martin-fastly, that's great news! I'm going to assign you to the issue for now:

@rustbot assign @katie-martin-fastly

One thing to mention is that most Rust compiler development discussion takes place on the rust-lang zulip, and this project in particular is chatting in #project-ffi-unwind. I or @Amanieu are probably reasonable people to ping with questions. Also, for general "getting started" tips on building and testing the Rust compiler, the rustc-dev-guide is your friend. Also, rust-analyzer works well for IDE support (e.g., with vscode), though it requires a small bit of configuration since rustc doesn't build with cargo but rather the x.py script. (I couldn't find any documentation on that, I'll ping a few others and see...)

That said, in terms of mentoring and getting started, I think the idea is going to be to adapt an existing mechanism that the compiler offers. We have this attribute #[unwind(allowed)] which allows users to mark functions as permitting unwinding -- that mechanism is basically going to be deprecated and replaced with this new ABI, though I think it'd be best to add the ABI before trying to adapt the unwind attribute code. Still, searching for code related to that attribute will give you a good idea of what needs to change.

I can do more mentoring instructions later but, as a starting point, I updated the head post with some of the major goals of the RFC (see the "Implementation notes") section. Also here are some tips to get you started in terms of reading into the rustc code:

• The Abi enum lists out all the known ABIs (there may be more similar enums, not sure). We'll want to extend it with C-unwind and perhaps other unwind variants. One way to do this might be to change the C variant to C { unwind: bool } or something like that, or maybe just add a Cunwind, not sure.
• The UnwindAttr type records what kind of unwind attribute is placed on a particular function (is unwinding allowed? does it force an abort?)
• The find_unwind_attr function checks for what unwind attribute is placed on a particular function.
• The should_abort_on_panic function is used to decide when a function ought to, well, abort if a panic occurs (as the name suggests).
• The [can_unwind] field of this struct seems to be used to set the LLVM attribute "nounwind". I'm not quite sure where it gets set, but I have to stop now because it's Saturday :P so I'll leave that as an exercise to the reader.

[BatmanAoD]

@RalfJung @nbdd0121 @nikomatsakis @joshtriplett

What is the next step for the extern "C" change? Do I need to write a separate stabilization report? Gary, would you be willing to write the PR to remove the feature flag, since you made the first stabilization PR?

Since 1.72 will be released this Thursday, it may be too late to make it in time for 1.73, but I'd like to get it in for 1.74 if possible.

[RalfJung]

Yeah a stabilization report for the unwind guards would be needed, describing what would change when the feature flag becomes "always on" and the context needed to understand that change.

[nbdd0121]

Gary, would you be willing to write the PR to remove the feature flag, since you made the first stabilization PR?

Sure

[BatmanAoD]

Request for Stabilization

This is a request for full stabilization of the c_unwind feature, RFC-2945. The behavior of non-"Rust", non-unwind ABIs (such as extern "C") will be modified to close soundness holes caused by permitting stack-unwinding to cross FFI boundaries that do not support unwinding.

Summary

When using panic=unwind, if a Rust function marked extern "C" panics (and that panic is not caught), the runtime will now abort.

Previously, the runtime would simply attempt to unwind the caller's stack, but the behavior when doing so was undefined, because extern "C" functions are optimized with the assumption that they cannot unwind (i.e. in rustc, they are given the LLVM nounwind annotation).

This affects existing programs. If a program relies on a Rust panic "escaping" from extern "C":

• It is currently unsound.
• Once this feature is stabilized, the program will crash when this occurs, whereas previously it may have appeared to work as expected.
• Replacing extern "x" with extern "x-unwind" will produce the intended behavior without the unsoundness.

The behavior of function calls using extern "C" is unchanged; thus, it is still undefined behavior to call a C++ function that throws an exception using the extern "C" ABI, even when compiling with panic=unwind.

Changes since the RFC

None.

Unresolved questions

This feature does not affect the behavior of pthread_exit or longjmp, so stabilization will neither break existing code using these features nor provide any soundness guarantee.

Tests

"C" guaranteed to abort on panic

This test verifies that an extern "C" function that panic!s will always abort if the panic would otherwise "escape".

Documentation

The documentation PRs for this feature did not distinguish between the initial partially-stabilized behavior and the fully-stabilized behavior, so they already include the modifications to non-unwind ABIs.

• The Rustonomicon PR has already been merged.
• The Reference PR is still awaiting approval.

I've also opened an issue to discuss adding a brief note about this feature in the Book.

[BatmanAoD]

Opened a separate issue (#115285) at @joshtriplett's request, to enable re-using the FCP bot.