ffi-unwind

[nikomatsakis]

Summary

Working out the rules for cross-language unwinding as well as longjmp.

Status

This section lists the efforts that we are working towards.

"C-unwind" ABI

The "C-unwind" ABI allows you to invoke foreign functions that may unwind using the native ABI.

• Specification: RFC: 'C-unwind' ABI rfcs#2945 has been merged. This RFC introduces the "C-unwind" ABI.
• Implementation: We are looking for someone to implement! The tracking issue for the implementation work is Tracking Issue for "C-unwind ABI", RFC 2945 rust#74990.

Interaction with catch_unwind

We need to define what happens when foreign exceptions interact with catch_unwind.

longjmp compatibility

We need to define the conditions in which it is legal to longjmp through Rust frames. We've done some initial conversation about this.

Links

• Repository
• Zulip-stream: #project-ffi-unwind

[nikomatsakis]

2020-04-02: Working towards RFC

[nikomatsakis]

2020-04-09: BatmanAod opened a PR with draft of RFC

[nikomatsakis]

2020-04-30:
- The only question is whether to make it “defined behavior” if a foreign except propagates across a “C unwind” boundary (and there is no catch_unwind)
- Advantage: we probably want to support this
- Disadvantage: it will require a shim to catch C++ exceptions — this is probably necessary later, unless we reverse the “two ABIs” proposal
- Interesting downside of the “two ABI” design
- If you have a C function but it takes callbacks, then there could potentially be pressure to make callbacks into “C unwind” and the function too (for flexibility)
- but note that this is not a trivial change, necessarily, and indeed many C libraries are not ready for this to happen “just because”
- True, but just a downside of this approach.

[nikomatsakis]

2020-06-01:
- Plain Old Frames — for frames that don’t have a pending destructor or catch_unwind

[nikomatsakis]

2020-06-11:

We uncovered a few interesting things in discussing the latest draft. The most important is that we are not comfortable saying that longjmp functions can unwind Plain Old Frames (POF) without any further annotation, because that will hinder our efforts to optimize. For the time being, we plan to edit the RFC to leave the details of when longjmp is legal as TBD, but we discussed some possible alternative proposals here rust-lang/project-ffi-unwind#30.

[nikomatsakis]

2020-06-22:

• RFC 2945 opened
• Not just about "C" vs "C unwind" ABIs, but we currently use #[unwind(allowed)] for "system":

    extern "system" {
        #[unwind(allowed)]
        pub fn _CxxThrowException(pExceptionObject: *mut c_void, pThrowInfo: *mut u8) -> !;
    }

• Options:
  • add "system unwind", "stdcall unwind", etc
  • maybe "system" itself is redundant

[nikomatsakis]

2020-07-06:

• RFC is believed to be ready for FCP, needs someone from lang-team to review and fcp merge.
• We clarified that other ABIs (e.g., system) may have unwind variants (e.g., extern "system unwind").
• Josh: If there were an ABI that is used in some context where unwinding is always used, it's not useful to have a non-unwind variant of it, in practice there is often a "defacto no-unwind" guarantee. (Niko: but we may want to call it "foo unwind", even if there is no "foo").

[nikomatsakis]

2020-07-20:

• RFC has just entered FCP.
• Bikeshedding now about "C unwind" vs "C-unwind"

[nikomatsakis]

2020-07-27:

• Bikeshed resolved ABI name to "C-unwind".

[nikomatsakis]

2020-07-31:

• RFC: 'C-unwind' ABI rfcs#2945 is merged and tracking issue Tracking Issue for "C-unwind ABI", RFC 2945 rust#74990 is opened.