Package CoreCLR browser WebAssembly native symbol map

[lewing]

Description

CoreCLR browser builds already generate Emscripten's dotnet.native.js.symbols, which maps final dotnet.native.wasm function indices to native symbols. The CoreCLR browser runtime-pack harvest omits the file, so external profilers and debuggers cannot resolve stripped native runtime frames such as $func2243 without rebuilding the runtime.

Reproduction Steps

1. Build the CoreCLR browser runtime pack:

   PATH=/opt/homebrew/bin:$PATH ./build.sh -os browser -c Release -subset clr+libs

2. Confirm the map exists in the native build/runtime-pack staging directory:

   test -f artifacts/bin/microsoft.netcore.app.runtime.browser-wasm/Release/runtimes/browser-wasm/native/dotnet.native.js.symbols

3. Inspect the shipping package:

   unzip -l artifacts/packages/Release/Shipping/Microsoft.NETCore.App.Runtime.browser-wasm.*.nupkg | grep dotnet.native

The package contains dotnet.native.js and dotnet.native.wasm, but not dotnet.native.js.symbols.

Expected behavior

The CoreCLR browser runtime pack should include the existing Emscripten dotnet.native.js.symbols file beside dotnet.native.wasm, matching the Mono browser runtime-pack flow. Application build/publish should continue to deploy it only when WasmEmitSymbolMap=true.

The browser boot resource manifest should preserve SHA-256 metadata for both the final wasm and the symbol map so consumers can reject stale pairings after static-web-asset fingerprinting.

Actual behavior

The file is generated and installed by the native browser host build, and the WebAssembly SDK already knows how to classify and publish .symbols assets, but eng/liveBuilds.targets omits the CoreCLR map from LibrariesRuntimeFiles. Consequently the shipping runtime .nupkg cannot supply it to normal no-relink browser publishes.

Regression?

Unknown. CoreCLR browser native symbol-map generation and runtime symbolication were added before the current runtime-pack packaging path, but the shipping pack has not included the map.

Known Workarounds

Use a local unpackaged runtime build containing dotnet.native.js.symbols, or force an application native relink that regenerates the map. Neither is suitable for external profiler consumers of the normal runtime pack.

Configuration

• CoreCLR browser-wasm
• Release runtime build
• Emscripten 6.0.2
• Reproduced on macOS arm64

Other information

The current verified map is Emscripten's unchanged index:name format. An independent parser confirmed that its keys use the absolute module function-index space, including imports. Live Chrome validation stopped at stripped $func2243, which the sidecar resolves to InterpExecMethod(...); its caller $func2276 resolves to ExecuteInterpretedMethod.

R2R transition thunks are functions in separately loaded Webcil modules and are covered by their module-local name sections from #132906, not this native-host sidecar.

Note

This issue was generated by GitHub Copilot.

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• [browser][coreCLR] produce and consume dotnet.native.js.symbols #122647