[lld] [wasm-ld] Refactor WasmSym from static globals to per-link context (PR #134970)

Anutosh Bhat via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 8 23:17:52 PDT 2025


anutosh491 wrote:

Use case as per https://github.com/llvm/llvm-project/issues/134809

While running clang-repl in the browser, we would have 

1) A main module (main.wasm) is loaded once at startup.

2) The user compiles code snippets dynamically. Each snippet is compiled into a new side module (X.wasm) that is then dynamically linked into the main module.

3) During the compilation of X.wasm, it may internally instantiate a helper module (Y.wasm) — for example, during interpreter initialization (e.g., Cpp::CreateInterpreter()).

3) Each of these modules (X.wasm, Y.wasm, etc.) is produced by a separate invocation of wasm-ld, using similar command-line arguments and linker inputs but the processes are different

However, we encountered a state-leak problem in wasm-ld:

The WasmSym::initMemory symbol, once created in one link (e.g., for X.wasm), persists into subsequent linker runs (e.g., for Y.wasm) due to WasmSym being globally defined with static fields.

This causes inconsistencies such as createInitMemoryFunction() being triggered when hasPassiveInitializedSegments() is false — leading to crashes/assertions.

This surfaced as a misalignment between the actual linking context and the static WasmSym state, especially in scenarios where no segments required passive initialization, but initMemory was still marked live from a previous link.

https://github.com/llvm/llvm-project/pull/134970


More information about the llvm-commits mailing list