[browser][coreCLR] enable -O3 after emscripten bump#130111
Merged
Merged
Conversation
…ds (dotnet#128686) emsdk 5.0.6 (dotnet#113786) no longer strips wasm exports at -O3 metadce. Restore -O3 (revert the -O2 link workaround from dotnet#128567) and drop the explicit -Wl,--export for both __stack_pointer (global) and __coreclr_wasm_rtlrestorecontext_tag (tag). Both are exported via -sEXPORTED_FUNCTIONS (EmccExportedFunction) alone, verified with wa-info on the -O3 shared framework and the -O2 app relink; console-node sample runs (exit 3). Keep -lexports.js to preserve the raw export names.
Contributor
|
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the WASM/Browser CoreCLR build configuration to remove now-unneeded export-preservation workarounds and to restore the standard Release optimization behavior after the Emscripten/LLVM toolchain bump.
Changes:
- Removes the Browser-specific
-O2Release link optimization override so Browser builds follow the normal UNIX-O3Release configuration. - Drops explicit
-Wl,--export=__stack_pointerand-Wl,--export=__coreclr_wasm_rtlrestorecontext_taglink flags from Browser host / corerun / CoreCLR BrowserWasmApp, relying on the centralized-sEXPORTED_FUNCTIONSlist instead. - Keeps
-lexports.jsto prevent export-name minification (so JS-side lookups by raw export name continue to work).
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| eng/native/configureoptimization.cmake | Removes the Browser-only Release link -O2 special-case so Release Browser builds align with other UNIX targets. |
| src/native/corehost/browserhost/CMakeLists.txt | Removes explicit wasm --export flags for __stack_pointer and the EH tag, relying on -sEXPORTED_FUNCTIONS. |
| src/coreclr/hosts/corerun/CMakeLists.txt | Same export-flag removal for the corerun WASM link step. |
| src/mono/browser/build/BrowserWasmApp.CoreCLR.targets | Removes explicit wasm --export flags from the managed build pipeline’s emcc link args (still emits -lexports.js). |
maraf
approved these changes
Jul 2, 2026
lewing
added a commit
that referenced
this pull request
Jul 11, 2026
…tive (#130543) ## Summary Fixes the browser-wasm **CoreCLR** library test leg (`WasmTestOnChrome-CLR` → `System.Globalization.Extensions.Tests`), failing on `main` since 2026-07-09 with: ``` System.DllNotFoundException : Unable to load shared library 'libSystem.Globalization.Native' ... dynamic linking not enabled at Interop.Globalization.ToUnicode(...) at System.Globalization.IdnMapping.IcuTryGetUnicodeCore(...) ``` Tracked by #130479 (`blocking-clean-ci`). ## Root cause #130140 added `GlobalizationNative_InitOrdinalLowerCasingPage` to the generated `callhelpers-pinvoke.cpp` P/Invoke tables (browser + wasi) — correctly inserting the sorted entry and its `extern "C"` declaration — but did **not** update the hard-coded `EntryCount` in `s_PInvokeTables` (left at `33`, now `34` entries). `minipal_resolve_dllimport` (`src/native/minipal/entrypoints.h`) linearly scans `entries[0 .. count-1]`. With `count = 33` over the 34-entry table, the **last** entry — `GlobalizationNative_ToUnicode` — became unreachable, so its P/Invoke resolved to `NULL` and fell back to `dlopen` (unsupported for CoreCLR-wasm) → `DllNotFoundException`. This is why **only** `IdnMapping.GetUnicode`/`ToUnicode` tests failed while `GetAscii` (`ToAscii`, index 32, still in range) kept passing. The generator emits this count from the table length, so `34` is exactly what a regeneration produces; #130140 hand-edited the generated file without re-running it. ## Fix Bump the `libSystem.Globalization.Native` `EntryCount` from `33` → `34` in both: - `src/coreclr/vm/wasm/browser/callhelpers-pinvoke.cpp` - `src/coreclr/vm/wasm/wasi/callhelpers-pinvoke.cpp` All other module counts already match their tables (verified in both files). ## Regression window (bisected on `main`, definition 129) | Build | SHA | `LibraryTestsCoreCLR` | |---|---|---| | 1500867 (Jul 9 08:00) | `0f907bfa` (no #130140) | ✅ pass | | 1502091 (Jul 9 20:00) | `6c584914` (has #130140) | ❌ fail — same signature | Emscripten 5.0.6/LLVM23 (Jun 25) and -O3 (#130111, Jul 2) were ruled out — the leg stayed green with both for two weeks. ## Verification - Native reproduction against the real `minipal/entrypoints.h`: `ToUnicode` resolves `NULL` at count 33 and `FOUND` at count 34; `ToAscii` resolves at 33 (matches the observed pass/fail split). - The browser-wasm CoreCLR `WasmTestOnChrome-CLR` CI leg exercises this end-to-end. cc @tarekgh @pavelsavara @lewing > [!NOTE] > Root-cause investigation and this fix were produced with GitHub Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
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 #128686.
The emscripten 5.0.6 / LLVM 23 bump (#113786) no longer strips user-requested wasm exports during
-O3metadce, so the workarounds added in #128567 are no longer needed.Changes
-O2link special-case and let browser use-O3like the other UNIX targets (reverts the [browser][coreCLR] Export__stack_pointerglobal #128567 hunk; the file is now identical to its pre-[browser][coreCLR] Export__stack_pointerglobal #128567 state).-Wl,--export=__stack_pointerand-Wl,--export=__coreclr_wasm_rtlrestorecontext_tag. Both symbols are exported via-sEXPORTED_FUNCTIONS(theEmccExportedFunctionitems ineng/native.wasm.targets) alone.-lexports.js(MINIFY_WASM_EXPORT_NAMES=0) is kept so the raw export names remain un-minified for the JS-sidewasmExports['__stack_pointer']/ tag lookups.Testing
Built
clr+libs+hostfor-os browser -c Release(CoreCLR), 0 warnings / 0 errors, and inspected the exports withwa-info:-O3shared frameworkdotnet.native.wasm:(export "__stack_pointer" (GlobalIdx 0))(export "__coreclr_wasm_rtlrestorecontext_tag" (4 1))— the wasm tag (kind4) survives viaEXPORTED_FUNCTIONS.-O2app-relinkedconsole-nodesample wasm: both exports present as well.console-node(Release/CoreCLR) runs and returns the expected exit code3(args.Length), exercising reverse-pinvoke (__stack_pointer) and the EH path (__coreclr_wasm_rtlrestorecontext_tag).Note
This PR description was drafted with GitHub Copilot.