Exception handling instructions emitted on wasm even when exception-handling feature is disabled

[bjorn3]

I tried this code:

pub extern "C-unwind" fn gzgetc() -> i32 {
    42
}

pub extern "C-unwind" fn gzgetc_() -> i32 {
    gzgetc()
}

fn main() {
    for gzgetc_fn in [gzgetc, gzgetc_] {
        // gzgetc on a null file handle should return -1.
        assert_eq!(gzgetc_fn(), -1);
    }
}

compiled for wasm32-wasip1 or wasm32-unknown-unknown without -Ctarget-feature=exception-handling.

I expected to see this happen: No exception handling instructions emitted

Instead, this happened: catch_call is emitted for gzgetc_fn() when opt-level < 2.

Meta

rustc --version --verbose: Both 1.86 and nightly

This is causing failure to run on Wasmtime in some cases: trifectatechfoundation/zlib-rs#352 (comment)

[alexcrichton]

reduced slightly it looks like this generates exception-handling instructions too:

#[unsafe(no_mangle)]
pub extern "C-unwind" fn foo(x: extern "C-unwind" fn()) {
   x()
}

[alexcrichton]

Digging in a bit more:

• Compiling for MSVC removes cleanuppad instructions
• Compiling for MSVC with -Cpanic=abort does not remove cleanuppad instructions
• Compiling for wasm with -Cpanic=unwind remove the cleanuppad instructions
• Compiling for wasm with -Cpanic=abort does not remove the cleanuppad instructions

I think what's happening here is that the AbortUnwindingCalls pass is running and in -Cpanic=abort mode it's inserting a panicking shim around the invocation of this function pointer as, on native at least, the origin of the pointer could be an FFI definition which does actually unwind which would not be sound in Rust. I believe this is also why function pointers are required because calling a defined function in Rust has a special case of "we know that can't unwind" so the cleanuppad is skipped.

Two solutions I can think of are:

• Check for -Ctarget-feature=+exception-handling in AbortUnwindingCalls -- on one hand I think the fix for this is to add logic along the lines of "can this target ever possibly unwind?" and if the answer is "no" then the AbortUnwindingCalls pass is skipped. Sort of at least, passing -Z mir-enable-passes=-AbortUnwindingCalls results in an ICE so AbortUnwindingCalls needs to run to some degree. This then raises some uncomfortable ABI questions. For example it means you shouldn't be able to invoke -Ctarget-feature=+exception-handling for just one crate, it has to be true for an entire compilation. This means that when using precompiled standard libraries it should not be possible to turn on the +exception-handling feature, but using that would require -Zbuild-std in one form or another.
• Punt this to LLVM - another possible solution would be to file an issue with LLVM and request that these instructions turn into noops when the exception-handling target feature is disabled. I'm not sure how amenable LLVM would be to this though.

IIRC I remember seeing messages awhile back about "global" target features which is sort of what we'd want here I think, but I'm not sure if that implementation/idea materialized