Add wasm64-emscripten arm for unwinder_private_data_size#156912
Open
gergelyvagujhelyi wants to merge 1 commit into
Open
Add wasm64-emscripten arm for unwinder_private_data_size#156912gergelyvagujhelyi wants to merge 1 commit into
gergelyvagujhelyi wants to merge 1 commit into
Conversation
wasm64-unknown-emscripten is buildable as a tier-3 target via a custom JSON spec, but library/unwind has no cfg arm for it in this chain, so std builds fail with E0425 (unwinder_private_data_size unresolved). Mirrors the wasm32-emscripten arm right above. unwinder_private_data_size is a count of _Unwind_Word fields, not a byte size, so the value matches between wasm32 and wasm64 — only pointer widths differ.
Collaborator
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
10 tasks
gergelyvagujhelyi
added a commit
to nobodywho-ooo/nobodywho
that referenced
this pull request
May 25, 2026
Post-wasm64 audit caught three stale spots:
js/README.md "v1 limitations": the "Models >2 GiB on disk" item read
as a flat capability gap. Splits into two accurate items now:
- >2 GiB on disk via modelBytes in Node: use Chat.create({modelPath})
which streams chunks into MEMFS; browser is unaffected (modelUrl
streams via fetch + Cache API).
- >4 GiB total working set on wasm32: build the sibling wasm64
artifact; ceiling lifts to 16 GiB. Links rust-lang/rust#156912
for the unwind patch that's gating contributors today.
core/src/llm.rs get_model_from_path doc: parenthetical claimed the
wasm32 4 GiB ceiling "still applies" with no escape hatch. Updated to
point at the sibling wasm64 build script.
js/README.md cfg-shorthand: a stray `cfg(not(wasm32))` reference left
over from before the workspace-wide widening to
`cfg(not(target_family = "wasm"))`. Updated for consistency with the
code.
No functional changes.
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
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.
library/unwind/src/libunwind.rshas acfgdispatch on(target_arch, target_os)forunwinder_private_data_size. There's anarm for
wasm32-emscriptenbut none forwasm64-emscripten, sobuilding
stdforwasm64-unknown-emscripten(consumed as a tier-3target via a custom JSON spec and
-Z build-std) fails withE0425: cannot find value 'unwinder_private_data_size' in this scope.This PR adds the missing arm, mirroring the existing
wasm32-emscriptenvalue of20. The constant is a count of_Unwind_Wordfields in_Unwind_Exception, not a byte size, so thesame value is correct for both pointer widths — Emscripten's libunwind
is what determines how many private words the struct needs (~18 for
the libcxxabi
__cxa_exceptionoverlay, plus the standard Itaniumprivate_1/private_2), and that count is target-uniform.Context
wasm64-unknown-emscriptenisn't an officially listed target, but it'sbuildable today as a tier-3 target via a custom JSON spec mirroring
wasm32-unknown-emscriptenwitharch=wasm64,target-pointer-width=64, and Emscripten's-sMEMORY64=1inpost-link-args. The motivation is running LLM inference workloadswhose working set exceeds 4 GiB (model tensors + KV cache + compute)
in a browser via Emscripten, which is impossible on wasm32 regardless
of how the bytes are loaded.
Without this arm,
stditself fails to build because theunwindcrate is foundational — any crate using
String/Vec/ etc.transitively pulls in
unwind. With it, the entire toolchain chain(rustc → wasm-bindgen-cli → emcc post-link with
-sMEMORY64=1 -fwasm-exceptions) links cleanly and the resulting wasm runsreal-world inference workloads end-to-end. Verified with Gemma 3 4B
(~3.5 GiB on-disk; ~5 GiB working set) on Node 22.
Test plan
No new tests needed — the change is a single
constfor an inactivetarget. Existing CI continues to skip wasm64-emscripten (not in
src/tools/build-manifest/dist-various-2).Manual verification:
cargo +nightly build --target wasm64-unknown-emscripten.json -Z build-std=panic_abort,std -Zjson-target-specsucceeds for a minimalString-using cratewith this patch; fails with
E0425without it.Prior art for similar arms
The cfg chain in this file already has dedicated arms for several
tier-3 / late-tier-2 targets —
riscv32/riscv64,hexagon,loongarch32/loongarch64,wasm32-wasi,wasm32-emscripten. ThisPR follows the same pattern, adding only the missing
wasm64-emscriptenline.