Exclude symbols starting with '_Z' from user exports

[nickpdemarco]

Regression introduced in: Emscripten 4.0.3
Affects: SIDE_MODULE builds which contain mangled Rust standard library symbols.

SIDE_MODULE builds fail with "invalid export name" errors:

Reproduction: nickpdemarco/emsdk-export-bug

emcc: error: invalid export name: _ZN4core3fmt3num3imp52_$LT$impl$u20$core..fmt..Display$u20$for$u20$u32$GT$3fmt17h745ee1c5d9dcaa78E

Emscripten's post-processing incorrectly classifies mangled symbols (internal implementation details) as user exports, triggering validation that fails on invalid WebAssembly identifier characters.

Note: this issue existed prior to 4.0.3, but this change exposed it.

Analysis

Expected behavior: Only explicitly requested functions should be exported from SIDE_MODULE builds
Actual behavior: Internal mangled symbols are misclassified as user exports

Pipeline breakdown (from debug analysis):

1. ✅ Rust/cargo: Correctly specifies EXPORTED_FUNCTIONS=["_add_numbers","_multiply"]
2. ✅ Emscripten linker: Correctly calls wasm-ld --export=add_numbers --export=multiply
3. ✅ wasm-ld: Successfully links WASM with only requested exports
4. ❌ Emscripten post-processing: Reads WASM file, incorrectly classifies internal _Z* symbols as user exports, validation fails

The problematic symbol exists in the WASM as an internal implementation detail but was never requested for export by the user or passed to the linker.

[sbc100]

I believe this was already fixed in #24367 which was part of 4.0.10. Can you confirm with 4.0.10 installed?

[nickpdemarco]

I can reproduce this on 4.0.11. I think the issue isn't $, but ... Notice there's double-dots a few times in this symbol

_ZN4core3fmt3num3imp52_$LT$impl$u20$core..fmt..Display$u20$for$u20$i32$GT$3fmt17h29cb94722fa2ffbaE

which I presume makes this an invalid JS identifier. In any case, I'm growing skeptical of this change (at least, by itself) because it's leading to prohibitively long link times in the side_module files I build.

[sbc100]

In that case I think #24427 will likely fix the issue since it skips the check for side modules exports.

[nickpdemarco]

Unfortunately I don't think it does - I just installed tot, confirmed that #24427 appeared in the sources, and I reproduced the same issue mentioned in this description.

I should say, I am trying to generate JavaScript, and run it with node. 24427 seems exclusively related to the case where we don't emit JS. Regardless, I think we have a regression - with 3.0.1 I was able to build a cdylib with cargo and link it into a main.cpp built with em++. I'm still trying to figure out what the root cause is.

[sbc100]

I don't think this is the correct fix for the issue. Can you open a bug describing the problem? Please include the full link command used to link the program. My guess is that the symbols in question are not supposed to be exported but for some reason llvm is marking that for expoort.