Repository navigation
Support bun:ffi on Windows ARM64 #28055
Description
What is the problem this feature would solve?
Windows ARM64 support landed in #26215, but bun:ffi is still completely disabled on that target.
Today we explicitly gate it off in:
cmake/Options.cmake(DEFAULT_ENABLE_TINYCC OFFonWIN32 && aarch64)src/bun.js/api/ffi.zig(cc(),callback(),dlopen(),linkSymbols()all throw when TinyCC is disabled)test/js/bun/ffi/*(Windows ARM64 is treated as FFI-unavailable)
So native Windows ARM64 Bun exists, but any FFI-backed app/library still fails there.
This seems like the missing follow-up to #9824 / #26215.
What is the feature you are proposing to solve the problem?
Enable bun:ffi on native Windows ARM64.
Concretely, that likely means:
- vendor/bump TinyCC to a revision that includes the Windows ARM64 work
- get Bun’s FFI path green on real Windows ARM64
- unskip/enable the FFI tests on Windows ARM64
- flip
ENABLE_TINYCCon for that target once stable
Relevant detail: Bun is still pinned to an older TinyCC revision in cmake/targets/BuildTinyCC.cmake, while the Windows ARM64 TinyCC work appears to have landed later upstream.
If the plan is not full TinyCC-backed support, it would still be useful to track whether dlopen() / fixed-symbol calls can be split from the TinyCC dependency.
What alternatives have you considered?
- x64/baseline Bun under emulation: works around it, but not a real fix
- app-level fallbacks: useful UX-wise, but doesn’t address the platform gap
Reacted by Lars Gyrup Brink Nielsen, Adam Hassan, 조효재 (Hyojae Cho), ABrauser and Thomas
Activity
bold84 commentedon Mar 14, 2026
TinyCC doesn't support Windows on ARM64 yet. But I have already implemented it using GPT 5.4 with Codex and will create a PR at TinyCC soon.
bold84 commentedon Apr 7, 2026
oven-sh/tinycc#2
There you go...
Billzhong2022 commentedon Apr 28, 2026
Hi team,
I've reproduced same issue on Windows Arm PC. When will you fix it? Please help share ETA to us.
Thank you very much!
Jarred-Sumner commentedon Jul 7, 2026
Status update for anyone following: PR #29476 now enables the Rust-side TinyCC gate on Windows ARM64 as well — see #29476 (comment) for why earlier CI results on that PR were not meaningful for this platform.
Jarred-Sumner commentedon Jul 10, 2026
Status: this now has a concrete two-step path. The
illegal instructioncrashes that appear oncebun:ffiis actually enabled on windows-aarch64 (#29476) are a missing post-JIT instruction-cache flush in TinyCC's Windows path — already fixed inoven-sh/tinycc@c22ca054, which #33653 pins (with its requiredlibtcc1.ccompanion). So: merge #33653, then rebase #29476 on it; #29476'swindows-11-aarch64lane is the acceptance test. Analysis with the failing-lane evidence: #29476 (comment)Jarred-Sumner commentedon Jul 10, 2026
Correction to my last comment, and the real status: this is solved. Draft PR #33696 (TinyCC upgrade + Windows-ARM64 enablement) has a passing
windows-11-aarch64-test-bunlane — thebun:ffisuites run and pass on real Windows ARM64. It required two TinyCC fixes, both already inoven-sh/tinycc: the arm64 post-JIT icache flush (c22ca054), and — the one my earlier comment missed, which was the actual remaining killer — an LLP64 immediate-width bug where~0xfffulzero-extends on Windows hosts so1<<49(JSC's DoubleEncodeOffset in every FFI trampoline) silently dropped out of the generated code (8a6cbc12). Remaining work is only mechanical: #33696 drops its two temporary diagnostic commits and undrafts (see also #33653, the TinyCC upgrade it builds on). #29476 appears superseded by it.Enable bun:ffi (TinyCC) on Windows ARM64 (#33696)
the aarch64-windows-ucrt leg: bun-windows-aarch64 on windows-11-arm