Add a CI check that the checked-in wasm CoreCLR call helpers are up to date

[lewing]

The checked-in CoreCLR WebAssembly call-helper tables (src/coreclr/vm/wasm/{browser,wasi}/callhelpers-*.cpp) are generated from the framework's [UnmanagedCallersOnly] methods, P/Invokes and QCalls. Nothing checked that they still match the managed code. A stale table still builds, but the corerun that links it crashes. #134978 enabled FEATURE_PERFTRACING on WASI without regenerating the tables. The EventPipeEventProvider.Callback reverse thunk was missing, and every corerun built from the checked-in tables then failed at startup with GetUnmanagedCallersOnlyThunk: unknown thunk in CoreCLR_WASI_RuntimeTests. Library tests did not catch it because app relink generates per-app tables.

Related: #133187

Changes

• Generator: generate-coreclr-helpers.proj gains an optional CallHelperTargetOS property (browser or wasi). The .sh and .cmd scripts expose it as -t / --target-os, so a build that produced only one flavor can regenerate just that flavor. An invalid value gets a clear error.
• CI step: the new eng/pipelines/common/templates/wasm-coreclr-callhelpers-check.yml regenerates the leg's own flavor. If src/coreclr/vm/wasm/<os>/ then differs from what is committed, it fails with a ##vso error, the diff, and the exact build and regenerate commands. It runs as a post-build step on two existing legs, so no new leg is added:
  • the Release browser_wasm CoreCLR leg (Linux host only; the step skips itself on browser_wasm_win);
  • the wasi_wasm CoreCLR build-only leg.
• Triggers: a new wasm_coreclr_callhelpers path subset is OR'd into both legs' conditions, so managed-only interop changes run the check. It covers src/libraries/*/src/*, src/coreclr/System.Private.CoreLib/*, src/coreclr/tools/aot/ILCompiler.ReadyToRun/*, src/coreclr/tools/Common/*, src/coreclr/vm/wasm/* and eng/wasm/WasmPInvokeModules.props. This deliberately widens which library PRs run these two legs.
• Docs and default configuration: the scripts now default to -c Release. generate-coreclr-helpers.md documents --target-os, the canonical configuration, and the CI check.
• Regenerated WASI table (separate commit): changes comments only in wasi/callhelpers-pinvoke.cpp, so the check starts green.

Does the output depend on configuration?

I regenerated the tables from several configurations and diffed the results:

Flavor	Inputs compared	Result
wasi	Release vs Debug (clr+libs -c ...)	Same entries. One comment differs: Debug System.Net.NameResolution still references SystemNative_GetErrNo; Release trims it.
wasi	Release libs + Release CoreLib vs Release libs + Checked CoreLib (-rc Checked -lc Release)	Byte-identical
wasi	Release crossgen2 vs Checked crossgen2 (same scan path)	Byte-identical
browser	Release vs Debug	Byte-identical, and identical to main

Entries do not depend on configuration, so one set of tables serves every configuration's corerun. Only the // <assembly>, ... comments on P/Invoke entries vary, because library trimming differs by configuration. Release is therefore the canonical configuration: CI builds Release, and the check compares against it exactly. The WASI table on main had been generated from Debug libraries. It also predated #130463, which moved the WASI socket interop into CoreLib. Regenerating from Release changes three comments:

-    DllImportEntry(SystemNative_GetErrNo) // System.Net.NameResolution, System.Private.CoreLib
+    DllImportEntry(SystemNative_GetErrNo) // System.Private.CoreLib
-    DllImportEntry(SystemNative_GetWasiSocketDescriptor) // System.Net.Sockets
+    DllImportEntry(SystemNative_GetWasiSocketDescriptor) // System.Private.CoreLib
-    DllImportEntry(SystemNative_WasiSubscribeSocketPollable) // System.Net.Sockets
+    DllImportEntry(SystemNative_WasiSubscribeSocketPollable) // System.Private.CoreLib

Validation (local, macOS arm64 host)

Command	Result
./build.sh clr+libs -os wasi -c Release	Passed
./build.sh clr+libs -os wasi -c Debug	Passed
./build.sh clr+libs -os wasi -rc Checked -lc Release	Passed
./build.sh clr+libs -os browser -c Release / -c Debug	Passed (emsdk needed EMSDK_PYTHON pointing at Python ≥ 3.10 locally)
src/coreclr/vm/wasm/generate-coreclr-helpers.sh -c Release --target-os wasi	Passed; regenerated only wasi/, browser/ untouched
src/coreclr/vm/wasm/generate-coreclr-helpers.sh -c Release --target-os browser	Passed; no diff against main
src/coreclr/vm/wasm/generate-coreclr-helpers.sh (no --target-os)	Passed; both flavors generated as before
generate-coreclr-helpers.sh -t foo	Fails as expected: Invalid target OS "foo"
dotnet build generate-coreclr-helpers.proj -t:GenerateCallHelpers -p:CallHelperTargetOS=linux	Fails as expected: Unknown CallHelperTargetOS 'linux'
Check-step script body, osGroup=wasi, _BuildConfig=Release, on main's stale WASI table	Exit 1; error, diff and fix commands printed
Same script on this branch's clean tree	Exit 0: "The checked-in wasi call helpers are up to date."
Same script after committing a WASI table with one reverse-thunk entry removed	Exit 1; diff shows the missing entry

Not validated: the pipeline YAML (the step template, the leg hookups, and the new path subset with its conditions) can only be verified in CI. The .cmd changes have not been run on Windows.

Note

This PR description was generated with the help of GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 6 pipeline(s).
10 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot review overview

🟡 Changes recommended

The Windows script cannot process --target-os and mishandles help arguments because its target label is missing.

Review effort: Balanced
Findings: 1

Open (1)

• Fix target OS option label and restore help handling · New

What changed in this PR

Adds CI validation to keep checked-in CoreCLR WebAssembly call-helper tables synchronized with managed framework code.

Changes:

• Adds target-specific helper generation for browser and WASI.
• Runs regeneration checks in existing CI legs with expanded path triggers.
• Documents Release as canonical and refreshes WASI comments.

Summary: Needs changes because the Windows wrapper’s new argument parsing is broken.

File	Description
src/​coreclr/​vm/​wasm/​wasi/​callhelpers-pinvoke.cpp	Refreshes generated assembly comments.
src/​coreclr/​vm/​wasm/​generate-coreclr-helpers.sh	Adds target selection and Release default.
src/​coreclr/​vm/​wasm/​generate-coreclr-helpers.proj	Supports target-specific generation.
src/​coreclr/​vm/​wasm/​generate-coreclr-helpers.md	Documents generation and CI validation.
src/​coreclr/​vm/​wasm/​generate-coreclr-helpers.cmd	Adds Windows target selection; contains a blocking parser defect.
eng/​pipelines/​runtime.yml	Hooks checks into browser and WASI legs.
eng/​pipelines/​common/​templates/​wasm-coreclr-callhelpers-check.yml	Implements regeneration comparison.
eng/​pipelines/​common/​templates/​wasi-wasm-coreclr-build-only.yml	Adds the WASI post-build check.
eng/​pipelines/​common/​evaluate-default-paths.yml	Adds relevant path triggers.

[radekdoulik]

LGTM, it would be nice to have it produce patch file in the artifacts.

[lewing]

/ba-g failures are unrelated