Repository navigation
fix(cpn): set correct WAMR build target per slice in macOS universal builds - #7946
Merged
Merged
Conversation
…builds WAMR derives a single BUILD_TARGET_* from the host CPU. On the arm64 CI runner a universal (x86_64;arm64) build therefore compiles the x86_64 slice with BUILD_TARGET_AARCH64, so wasm_runtime_invoke_native lays out 8 integer register slots while invokeNative_em64.s expects 6. Native and WASI calls passing stack arguments (e.g. path_open) receive garbage and the simulator hangs on Intel Macs. Override the target define per architecture with -Xarch_ flags. Fixes #7660 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The patch was re-applied on every configure against the cached WAMR source, failing with "patch does not apply" and a warning on repeat runs. Check with git apply --reverse --check first and skip if present. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
FetchWamr.cmake and its patches affect the Companion simulator build but were not in the workflow path filters, so changes to them did not trigger CI. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#7496 added CSD203 module/system current and voltage readouts to the module setup page and charge UI, but the getters only exist in the STM32 csd203_sensor driver, so the v16 WASM simulator failed to link. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
pfeerick
force-pushed
the
fix/wamr-macos-universal
branch
from
October 25, 2026 10:15
35b6d71 to
59f3803
Compare
pfeerick
marked this pull request as ready for review
October 25, 2026 11:17
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.
Fixes #7660
Problem
The macOS Companion CI job runs on
macos-15-arm64withCMAKE_OSX_ARCHITECTURES=x86_64;arm64. WAMR derives a singleWAMR_BUILD_TARGETfromCMAKE_SYSTEM_PROCESSOR, so it picksAARCH64and adds-DBUILD_TARGET_AARCH64to both slices.WAMR's assembly is universal-aware (
invokeNative_osx_universal.spicks em64 or aarch64 via__aarch64__), but its C side is not. Inwasm_runtime_common.c,MAX_REG_INTSis 8 underBUILD_TARGET_AARCH64, so the x86_64 slice packs native-call argv with 8 integer slots.invokeNative_em64.sexpects 6 and reads stack args fromargv + 64+48. Any host or WASI call that passes arguments on the stack (e.g.path_open, 9 args) gets garbage. The simulator then stalls afteredgeTxInit, and a reload showsout of bounds memory access.Arm64 is unaffected, and local Intel builds work because they aren't universal and detect
x86_64.Fix
For universal macOS builds, override the target define per slice on
vmlibwith-Xarch_x86_64/-Xarch_arm64-U/-Dflags. Compile options come after the directory-Ddefinitions on the command line, so the overrides win.Also: the WAMR
win_file.cpatch is now idempotent and skipped when already applied (git apply --reverse --check), so repeat configures no longer print a "patch does not apply" error and warning.Also fixes the v16 simulator link failure introduced by #7496 (
getSystemCurrent,getIntModuleCurrent,getExtModuleVoltage,getExtModuleCurrentundefined in the WASM build), by adding zero-value CSD203 stubs totargets/simu/adc_driver.cpp. And addscmake/FetchWamr.cmake/cmake/wamr-*.patchto the Companion workflow path filters.Testing
vmlibon Apple Silicon: the compile line shows the overrides after-DBUILD_TARGET_AARCH64, andlibiwasm.aisx86_64 arm64.BUILD_TARGET_X86_64, arm64 onlyBUILD_TARGET_AARCH64. Without the flags, the x86_64 slice hasBUILD_TARGET_AARCH64.edgetx-devdocker image: unaffected (no-Xarchflags emitted).FLAVOR=v16 tools/build-wasm-modules.shnow linksedgetx-v16-simulator.wasm.🤖 Generated with Claude Code