Add support for exceptions in LLVM #5347

xdoardo · 2025-01-15T14:17:39Z

This PR adds support for exceptions in LLVM for linux-64 targets.
This is of course still experimental. Missing bits:

Figure out EH in macOS (compact_unwind sections)
Figure out EH in windows
Add a bit of documentation

…n, throw, rethrow..) This commit adds (half of) the important functionalities for exception handling: the personality function - in part adapted from Rust's stdlib, which however does not do any "typechecking" in the sense that every "catch" block is akin to a "catch_all" (while we need to catch the correct `Tag`); the `throw` and `rethrow` mechanisms, and functions to allocate, delete and "read" an exception.

This commit adds the code to generate `landingpads` and `catch`es in LLVM.

…t_unwind` tables for Mach-O (Work in progress) macOS uses a different scheme for exception handling in Mach-O; in contrast with the "usual" .eh_frame mechanism, Mach-O has a `compact_unwind` section in which EH-related metadata are embedded. This commit begins the effort to support it in its entirety. On the path to that end, it also adds GOT-based relocations, which are necessary for Mach-O object files.

syrusakbary · 2025-01-15T14:28:28Z

lib/types/src/libcalls.rs

@@ -183,6 +204,13 @@ impl LibCall {
            Self::ImportedMemory32AtomicWait64 => "wasmer_vm_imported_memory32_atomic_wait64",
            Self::Memory32AtomicNotify => "wasmer_vm_memory32_atomic_notify",
            Self::ImportedMemory32AtomicNotify => "wasmer_vm_imported_memory32_atomic_notify",
+            Self::Throw => "wasmer_vm_throw",
+            Self::Rethrow => "wasmer_vm_rethrow",
+            Self::EHPersonality => "__gxx_personality_v0",


This function can't be named other way, right?

It can on Linux, apparently can't on macOS. Not sure about windows.

edit: It can't on macOS because, as far as I can tell, changing the name of the personality function makes LLVM generate different (wrong?) EH info in the object file.

syrusakbary · 2025-01-15T14:32:22Z

lib/compiler/src/translator/module.rs

-            Payload::TagSection(_) => {
-                unimplemented!("exception handling not implemented yet")
-            }
+            Payload::TagSection(t) => parse_tag_section(t, environ)?,


Since we are enabling this in the parser now, we'll need to make sure that the cranelift compiler fails with an exception/Error instead of panicking

syrusakbary · 2025-01-15T14:33:25Z

lib/compiler-cranelift/src/translator/translation_utils.rs

@@ -54,7 +54,7 @@ pub fn type_to_irtype(ty: Type, target_config: TargetFrontendConfig) -> WasmResu
        Type::F32 => Ok(ir::types::F32),
        Type::F64 => Ok(ir::types::F64),
        Type::V128 => Ok(ir::types::I8X16),
-        Type::ExternRef | Type::FuncRef => reference_type(target_config),


If ExceptionRef is passed, should we return an error? (since cranelift doesn't support it)

syrusakbary · 2025-01-15T17:14:19Z

lib/api/src/entities/value.rs

@@ -253,6 +303,7 @@ impl std::fmt::Display for Value {
                Self::I64(v) => v.to_string(),
                Self::F32(v) => v.to_string(),
                Self::F64(v) => v.to_string(),
+                Self::ExceptionRef(_) => "exceptionref".to_string(),


I think this is commonly known as exnref

syrusakbary · 2025-01-15T17:14:59Z

lib/api/src/rt/js/entities/exception.rs

+#[derive(Debug, Clone)]
+#[repr(transparent)]
+/// A WebAssembly `exnref` in `js`.
+pub struct ExceptionRef;
