Force wasixcc to legacy EH to match the Rust toolchain - #84
Merged
Conversation
The Rust toolchain builds in the legacy exception-handling configuration (its sysroot is the legacy-EH wasix-libc build), but wasixcc defaults to exnref, so the auto-configured C/C++ side of a build ended up in a different EH configuration than the Rust side. Set WASIXCC_WASM_EXCEPTIONS=legacy alongside the tool variables — overriding any value from the environment, since a mismatched configuration must not reach the build. wasm-opt still translates the final module to exnref in post-processing. The -dl target's WASIXCC_WASM_EXCEPTIONS=1 (exnref) default is gone for the same reason; with legacy EH, WASIXCC_PIC=1 selects sysroot-ehpic, matching the Rust dl target's sysroot32-ehpic. Verified with C setjmp/longjmp linked through the cc crate: the object now compiles as legacy EH (1 legacy try, 0 try_table pre-wasm-opt), translate-to-exnref unifies the module (1 try_table post), and the binary round-trips a longjmp under wasmer. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The Rust toolchain builds in the legacy EH configuration —
build-wasix.shbakes wasix-libc'ssysroot32-eh/sysroot32-ehpicinto the toolchain, and the target spec never passes--wasm-use-legacy-eh=false. wasixcc, however, defaults to exnref (WASM_EXCEPTIONSunset →sysroot-exnref-eh+--wasm-use-legacy-eh=false). So with the auto-CC integration, the C/C++ objects in a build were in a different EH configuration than the Rust/libc side.In practice this happened to work — Rust is panic=abort (no catches),
throwis style-neutral, and wasmer supports exnref — but it's an asymmetry waiting to bite (e.g. once anything on the Rust side emits legacy catches next to exnref C catches withwasm-opt = falseset).What
WASIXCC_WASM_EXCEPTIONS=legacyunconditionally, overriding any environment value — a mismatched EH configuration must not reach the build. Everything is still translated to exnref by the mandatorywasm-opt --translate-to-exnrefpass.-dltarget's oldWASIXCC_WASM_EXCEPTIONS=1(exnref) default;WASIXCC_PIC=1remains, and with legacy EH it selectssysroot-ehpic— the same configuration as the Rust dl target'ssysroot32-ehpic.Verified
C
setjmp/longjmpcompiled via the cc crate into a Rust app:try, 0try_table(wasixcc now matches the toolchain),try_table, 0 legacy (translate-to-exnref unifies),Integration test updated: asserts
legacyfor the dl target and asserts that anexnrefvalue in the environment is overridden.🤖 Generated with Claude Code