"C unwind" RFC

[BatmanAoD]

Based on "option 2" from the Internals post

[nikomatsakis]

Gave a quick read. Nice job, thanks for whipping this up. Here are some initial thoughts.

[bjorn3]

Can the personality function detect if a function requires cleanup? In that case it would be nice to abort the process on forced-unwinding of drop frames on at least some systems.

[BatmanAoD]

@bjorn3 Amanieu might be able to answer that, but even if it can't, the destructors themselves could do that. It's sort of expensive to insert that logic everywhere, though, so we'd only want to do that in debug mode.

[nikomatsakis]

I think that, at present, we were saying that it was still UB for a C++ exception to propagate across Rust frames, right?

Or, at minimum, we've not defined what the interaction with catch_unwind should be.

Though I think I would be ok with saying "catch-unwind will abort" and then discussing the possibility of adding some new mechanism later.

This would basically mean that one can "propagate C++ exceptions" in the manner described here, but only if you carefully control the Rust code in between and you know that it will not attempt to use catch_unwind.

[nikomatsakis]

I'd be curious to hear what @rust-lang/lang thinks about this, as well as @Amanieu -- how far do we want to go in terms of defining the interaction between "foreign" unwinding like C++ and Rust frames?

[BatmanAoD]

In the interest of simplicity for the initial specification, I would prefer to leave the interaction with catch_unwind TBD (formally UB) for now, even if the initial implementation aborts.

[BatmanAoD]

I've added some verbiage about our usage of "TBD".

[nikomatsakis]

So do you think we should say:

• propagating a C++ exception is OK (with "C unwind" and "panic=unwind")
• but not if there is catch_unwind?

This does imply that panic=abort would have to intercept the C++ exception and abort.

[BatmanAoD]

Yes, I think that's accurate. I think we already had the panic=abort requirement?

[nikomatsakis]

I think it might be helpful to have a list of scenarios and a description of what works and what doesn't.

Scenario	Works
C++ exception propagating across Rust frames	✔️
C++ exception propagating across catch_unwind	❌ -- Currently UB, TBD
Rust panic propagating across a "C unwind" frame	✔️

the challenge here though is how to really do this table, the textual descriptions aren't that great. Also I think it'd be worth being specific about showing the ABI details.

[nikomatsakis]

I guess there is a similar table in the "detailed design" section.

[nikomatsakis]

I feel like I personally would like to see a list of scenarios we considered and which ones work and which ones don't. At least, as a user I would find that very useful.

[nikomatsakis]

To some extent I am doing the work I think we'd need to do to document this properly in the reference or other docs, but I think that is indeed the role of this section.

[BatmanAoD]

Hm. I'm not sure I see a significant difference between what you're asking for and what's provided in the current draft. Though I do think that green/red checkmarks in the tables would be pretty... 😄

[nikomatsakis]

well, I don't think the draft actually lists out scenarios very thoroughly, and arranging them a table makes them easier to understand. It's more a matter of degree than anything.

[nikomatsakis]

I was going to say that we should list out the design constraints that led us here. I guess that this section goes in that direction. This was my list:

• Able to fully remove all unwinding machinery from panic=abort builds.
• Able to change Rust panics to an alternative implementation beyond native system unwinding if desired, by inserting "translation shims" at "C unwind" call sites. This is possible under either implementation, but such shims would be much more widespread with a single ABI.
• Repair the soundness hole when defining safe Rust functions with "C" ABI that panic (by aborting or translating the panic into a foreign exception). All designs did this equally well, either by aborting or by simply propagating the panic naturally.
• Permit a Rust panic to propagate across foreign frames and re-enter Rust code.
• Support longjmp/forced exceptions with "C" ABI, as many common C functions may unwind in this way. This proposal handles this case so long as there are no destructors, which was deemed adequate, as these features are highly platform dependent and not really suitable for widespread use.

[BatmanAoD]

Hm, several of these are listed in the blog post; perhaps we should link to that? In this section, I focused on differences compared to the other options we discussed in the design-meeting, rather than on our non-negotiable constraints.

[nikomatsakis]

We could link to the blog post, although I think it's good for the RFC to be reasonably self-contained. Or we could just copy some of that material into a different section. Honestly, I think I would typically put these sorts of constraints into the introduction

[acfoltzer]

Thank you so much for writing this up. This looks great to me, and would address all of our needs with Lucet.

[BatmanAoD]

Merging, though this is not quite ready to be submitted to the rfcs repo.