Skip to content

Should Wasmtime be using C-unwind ABIs in more places #10923

Open
@alexcrichton

Description

@alexcrichton

Spinning out the discussion from here and today's Cranelift meeting. The question is should Wasmtime be using C-unwind in more locations?

Current state of the world that this could apply to:

Rust defines foreign unwinding here, specifically:

Unwinding with the wrong ABI is undefined behavior:

  • Causing an unwind into Rust code from a foreign function that was called via a function declaration or pointer declared with a non-unwinding ABI, such as "C", "system", etc. (For example, this case occurs when such a function written in C++ throws an exception that is uncaught and propagates to Rust.)

If "causing an unwind" includes longjmp and custom Cranelift-defined unwinds then every single location listed above is UB. @bjorn3 mentioned this shouldn't work at all on Windows right now, but something must work on Windows insofar that tests are passing, and we didn't bottom it out in the Cranelift meeting what was going on.


In short, extern "C" guarantees that there's a aborting landing pad to catch unwinds, and we're guaranteed to skip it in all of the above cases as longjmp doesn't run this landing pad (nor does Cranelift-based unwinding). With extern "C-unwind", however, it's still the case that longjmp and Cranelift don't run Rust landing pads which is still UB if they exist (in theory).

In essence I'm not sure how best to proceed here. At the end of the day at a functional level we want a guarantee that when we longjmp in Wasmtime there's no Rust destructors on the stack, but even if that is the case (as we think it is today) it's still not clear whether this is all UB and needs to change one way or another. Will changing to C-unwind fix things? Do we need to use inline assembly stubs or similar more aggressively?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions