Where should `__cpp_exception` be defined?

[alexcrichton]

There's been some recent activity on __cpp_exception, where it's defined, etc, and I've encountered a new issues today which prompts me to raise a question here to get some broader feedback.

As a bit of background, my understanding is that the @llvm.wasm.throw intrinsic in LLVM takes an argument of "what type should be thrown", and this type is either 0 meaning "a C++ exception" or 1 meaning "a C longjmp exception". There is currently no ability to decide to throw some other kind of exception meaning that when an exception is thrown it must mean that either __cpp_exception or __c_longjmp is reference as a tag. Historically I believe wasm-ld would define __cpp_exception and __c_longjmp weakly in a all objects, but that (somewhat) recently changed to not doing so. LLVM switched to defining these two symbols in compiler-rt, but I sent PRs to remove those from compiler-rt under the rationale of "not suitable to link twice in multiple shared objects" since there should only be one definition of these symbols. This leaves us today with the current state of affairs: __c_longjmp is defined, for example, in wasi-libc and __cpp_exception is defined in libunwind.

The issue/question that prompted me to raise this here is this comment, which is: what should Rust do for its panics? A panic in Rust is similar (ish) to a C++ exception, and for Rust panics right now they're implemented with __cpp_exception. With these changes about the definition of __cpp_exception, it's not clear to me how this should work in Rust. Thus the crux of this question here: for languages that aren't C++, and for implementations that aren't longjmp, how should exceptions be thrown?

Some various ideas I have are:

• LLVM should have a language-specific exception tag definition for all languages that want to throw exceptions. For example LLVM should grow knowledge of __rust_panic as an exception tag that is suitable for use in Rust. I don't know off the top of my head, however, how much this affects catch-style blocks and how much those currently assume C++ vs being able to switch out to using some other kind of tag.
• All other languages should use __cpp_exception, and that should move its definition to a "libc-likelocation", e.g. wasi-libc or Emscripten's libc, instead of libunwind. That way languages can all use LLVM's support for __cpp_exception without necessarily using libunwind.
• All languages should use __cpp_exception, specifically through libunwind. For example Rust's custom implementation of throw/etc for wasm should be removed in favor of delegating to libunwind (similar to how native platforms work).

Each of these seems somewhat equally viable to me. Rust for example doesn't have a strong need to use a custom exception implementation, but at the same time it's also kind of nice not needing to distribute/build/etc libunwind. Nevertheless I wanted to open up the question here and see if others have thoughts, and I could very well be forgetting something here which would mean "nah there's just one answer".

[dschuff]

+cc @aheejin who can correct me if I'm wrong about any of this...

There was somewhat related discussion recently (llvm/llvm-project#169043, llvm/llvm-project#183753) about how this should work for Objc++, although in that case IIUC it's much closer to C++ and the C++ runtime can mostly be reused.

I think that it could be made to work either with or without __cpp_exception and the choice about whether to reuse the tag might depend on whether you'd also want to reuse the rest of the ABI contract between the compiler and the runtime. And maybe also about what we might expect to happen if we have a binary that uses both? One consequence of having different tags for C++ EH and longjmp is that they work together more-or-less how they would natively (longjmping over C++ frames will work, but cause leaks because the destructors don't run). Sharing the tag would mean you'd run C++ destructors during panic unwinding... which Is maybe not what you'd want?

[alexcrichton]

That spurs on two more thoughts from me. From Rust's perspective it does want to interoperate with C++ exceptions, so that may also limit the surface area of possible solutions here. The main point of interop is that, if Rust/C++ are correctly configured, it sould be able to throw a C++ exception across Rust frames and execute destructors. Similarly it should be possible to panic across C++ frames and run those destructors too.

The other thought though is:

longjmping over C++ frames will work, but cause leaks because the destructors don't run

Is the current behavior of LLVM considered buggy then?

For this program:

#include <setjmp.h>
#include <iostream>

static jmp_buf env;

void do_longjmp() {
  longjmp(env, 1);
}

void do_some_work() {
  struct A {
    int field;

    A(int f) : field(f) {}

    ~A() {
      std::cout << "A's destructor called, field = " << field << std::endl;
    }

  };

  A a(42);
  do_longjmp();

}

int main() {

    if (setjmp(env) == 0) {
      do_some_work();
    }

    return 0;
}

I see the output (built with this PR):

$ ./build/install/bin/clang++ foo.cpp -fwasm-exceptions -mllvm -wasm-use-legacy-eh=false -lunwind -lsetjmp -mllvm -wasm-enable-sjlj -o foo.wasm
$ wasmtime -Wexceptions foo.wasm
A's destructor called, field = 42

Specifically the cleanup in do_some_work uses catch_all_ref which means that any exceptions, be it C++ or longjmp, will execute destructors.

This isn't problematic per-se for Rust insofar as it means that even if we had a distinct tag for Rust it would mean that Rust's desired semantics of running cleanups would still work, but it could be problematic if longjmp is expected to specifically not run C++ destructors.

[dschuff]

No, it's just my memory that is buggy :)
I think at some point we must have discussed whether we wanted to use catch_all_ref vs just catch __cpp_exception which would have the leaking behavior. It's not super obvious which behavior one would really want (and it's UB to longjmp over any C++ frames that would invoke nontrivial destructors).
I do think that catch(...) is using the C++ tag, so if you want to appear as a foreign exception catchable in C++ you'd need to use the same ABI. Not sure you want that though.
For destructor interoperability then, it seems like it should be sufficient to do catch_all_ref in scopes that need destructors, call the destructor, and then throw_ref to continue propagation. (Assuming you want panics to be handled the same way as C++ exceptions).

Assuming you don't need actual catchability, then it seems all the options are on the table. libcxxabi on wasm doesn't really use libunwind the same way as it does on other platforms (because the unwinding is actually done by the engine and not by the library itself, the API doesn't really match up well with what happens on wasm).

[aheejin]

Ideally, I think any language implementer can define their own tag and doesn't necessarily have to deal with __cpp_exception and __c_longjmp if they don't use it. If the toolchain implementation is not exactly that way today and hardcode assumptions that tags should be either one of those two, we should fix it. Also, you shouldn't have to use libunwind if you don't want to. Also, I think reusing __cpp_exceptions is fine if any language implementer finds it convenient and it suits their needs.

@alexcrichton

I don't know off the top of my head, however, how much this affects catch-style blocks and how much those currently assume C++ vs being able to switch out to using some other kind of tag.

I can't think of one off the top of my head. When I grep the codebase with those tag names, I find some places that assume tag names should be either of __cpp_exception or __c_longjmp, but I think those can be easily fixable. I can't think of any fundamental assumption that prevents the use of other tags in the backend, but I might not remember everything. But in any case, they should be fixable. One thing I think that is closely related to Itanium ABI is https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/WasmEHPrepare.cpp. But I guess Rust people already dealt with it, because I remember getting some questions about this a long time ago?

@dschuff

And maybe also about what we might expect to happen if we have a binary that uses both? One consequence of having different tags for C++ EH and longjmp is that they work together more-or-less how they would natively (longjmping over C++ frames will work, but cause leaks because the destructors don't run). Sharing the tag would mean you'd run C++ destructors during panic unwinding... which Is maybe not what you'd want?

Destructors will be fine because they use catch_all / catch_all_ref.
EDIT: I opened this tab hours ago and missed new comments that already said this, sorry

[alexcrichton]

Do y'all have a sense for what other languages are trending towards? Or are the only examples right now Objective-C and Rust?

My thinking is that in the near-term it would probably makes sense to get Rust linking to libunwind to provide a canonical definition of __cpp_exception. Longer-term adding __rust_panic_tag or similar to LLVM which Rust would use. In all worlds though __cpp_exception stays out of libc-like binaries and remains in libunwind/C++ contexts. If other languages aren't expected to add their own tag types though it might be best to just stick to libunwind providing the canonical definition of __cpp_exception in the long term for Rust.

[aheejin]

Do y'all have a sense for what other languages are trending towards? Or are the only examples right now Objective-C and Rust?

No, I don't know other languages trying to add Wasm EH support other than those two.