[browser][coreCLR] Export __stack_pointer global#128567
Conversation
|
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
There was a problem hiding this comment.
Pull request overview
This PR updates the browser-wasm (CoreCLR) build/link configuration to ensure the __stack_pointer WebAssembly global remains exported in optimized builds, so JS code can access wasmExports.__stack_pointer when instantiating related modules.
Changes:
- Adds explicit linker export of the
__stack_pointerglobal (-Wl,--export=__stack_pointer) and ensuresexports.jsis linked where needed. - Adjusts CoreCLR browser-wasm relink arguments to include the new export flag and reposition
-lexports.js. - Updates shared wasm export lists and attempts to change browser Release optimization behavior to avoid toolchain DCE removing the global.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| src/native/corehost/browserhost/CMakeLists.txt | Adds -lexports.js and linker export for __stack_pointer to the browserhost link. |
| src/mono/browser/build/BrowserWasmApp.CoreCLR.targets | Updates CoreCLR relink args to include -lexports.js and -Wl,--export=__stack_pointer. |
| src/coreclr/hosts/corerun/CMakeLists.txt | Adds -lexports.js and linker export for __stack_pointer; removes explicit ___stack_pointer from EXPORTED_FUNCTIONS list. |
| eng/native/configureoptimization.cmake | Changes browser Release optimization intent to -O2 (to avoid metadce). |
| eng/native.wasm.targets | Adds ___stack_pointer to the exported function list for browser targets. |
|
Thank you for getting to the bottom of this. I'll test it out soon. |
|
I did It failed: |
|
Thanks @kg ! I made another change here and then used your tool
|
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
|
Helpers appear to be broken in Release builds atm but this indeed fixes running Hello World by preserving the export, thank you! EDIT: This is just because your branch is based on a point in time before i fixed write barriers, so everything looks good. |
|
/ba-g unrelated CI failures |

Problem
The
__stack_pointerWebAssembly global export was being removed from the final.wasmbinary despite being explicitly requested via-sEXPORTED_FUNCTIONS=___stack_pointerand-Wl,--export=__stack_pointer.This global is needed by
libCorerun.jsto share the stack pointer with dynamically loaded Webcil sub-modules (wasmExports.__stack_pointeris passed as an import to child wasm instances).Root Cause
Emscripten's
wasm-metadcepass (dead code elimination) unconditionally excludes all wasm global exports from its reachability graph:Since
__stack_pointeris a wasm global (not a function), it's never included in the DCE graph regardless ofEXPORTED_FUNCTIONS. Thewasm-metadcetool then considers it unreachable and removes it.Metadce runs when
OPT_LEVEL >= 3orSHRINK_LEVEL >= 1(i.e.,-O3,-Os, or-Oz).Fix
-O2for Browser Release builds inconfigureoptimization.cmake— this prevents metadce from running while still enabling wasm-opt optimizations.-Wl,--export=__stack_pointerto all Browser link targets (corerun, browserhost, BrowserWasmApp) to ensure wasm-ld emits the export.___stack_pointertoEmccExportedFunctionineng/native.wasm.targetsFollow-up
We should re-visit this after we upgrade emscripten, we could have more efficient way how to do it