ffi-unwind about lang-team

[nikomatsakis]

Update: PR is ready for review, and we'll have a longjmp blog post going out soon

[BatmanAoD]

2021-04-06:

• "C-unwind" PR was merged!
  • This accidentally introduced a change to "C" unwind behavior even without the feature flag; we will need to fix this before the next stable release. We have alerted the release team and are working on a fix.
  • There are a few more follow-up issues to address, listed here.
• a longjmp blog post was published, but we are prioritizing the "C-unwind" issues for now

[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:

• rust-lang/rfcs#2945 is merged and tracking issue rust-lang/rust#74990 is opened.

[nikomatsakis]

2020-09-14:

• Implementation work is ongoing, we may start looking at the longjmp question.

[nikomatsakis]

2020-09-21:

No update.

[joshtriplett]

Discussion in today's meeting:

• New discussion and proposals for handling "target ABI"
  • e.g. target for native iOS vs target for iOS simulator, which have different ABIs
  • Rust doesn't have a way to express this today

This isn't directly in the current ffi-unwind charter. Rather than expanding it (which we'd do to cover c++/longjmp/etc), we may need to consider chartering an additional project for new FFI issues.

[joshtriplett]

(Not sure why this unassigned @BatmanAoD; I didn't change anything there.)

[nikomatsakis]

Update:

• @BatmanAoD plans to write a blog post setting the direction for work on functions that can be deallocated ("canceled") with longjmp &c.
• @katie-martin-fastly hasn't had time to work on rust-lang/rust#76570 recently but hopes to get some more time soon =)

[nikomatsakis]

2020-11-17:

• Previous comment still basically accurate.

[nikomatsakis]

Lang team planning meeting update:

• We should promote this project to "evaluation"
• On the topic of longjmp:
  • Josh: Fairly unusual to see people using longjmp these days, should not sacrifice optimizablity
  • Josh: But it should be possible -- with enough care -- to longjmp without UB
  • Amanieu: this also affects functions that call pthread_exit
• Would be nice to open a PR and update the charter to include new scope (can link to the blog post)

[BatmanAoD]

• updated charter
• Follow-up issues for "C-unwind" remain our top priority.
  • In particular, we need to implement the specified "abort-on-unwind" behavior for "C-unwind" FFI calls in panic=abort mode.
• Regarding longjmp, we believe there's an LLVM bug causing incorrect code-gen when strict-aliasing is enabled in a frame that gets discarded by longjmp. We haven't yet discussed how to move forward, though we plan to open a bug report for it.

[nikomatsakis]

Update:

• @alexcrichton has a PR fixing various bugs and implementing the intended semantics, under review
• Plan of record is to
  • remove the UB from panics in "C" while adding "C-unwind" as a target
  • once "C-unwind" is stabilized -- hopefully soon! -- add back in the UB for panics in "C"

[nikomatsakis]

Closing in favor of rust-lang/project-ffi-unwind#36