[clementperon]

The first call to getFunctionAddress walks the whole table and keeps a JS function object for every entry. With MAIN_MODULE and pthreads, every worker makes that call when it instantiates the main module (updateGOT), so each worker holds a wrapper for every address-taken function of the main module for its whole lifetime.

The dynamic linker only looks up the main module's exported functions. So the main thread now records their table slots, and passes them to workers in the load message next to sharedModules. Right before updateGOT, a worker creates functionsInTableMap with just those slots. At that point the table only holds the main module. Side modules add their own slots when they are loaded, as before.

Both halves are in one function, initFunctionsInTableMap in libdylink.js. addFunction and getFunctionAddress are unchanged.

Impact

Kodi's WebAssembly port links Kodi as MAIN_MODULE=2 so binary add-ons can be dlopened. Its table has 50,551 slots, of which 102 hold exported functions. Measured in Chrome with the same wasm, applying this change to the Emscripten 6.0.9 glue:

	before	after
JS heap per worker, after an add-on is loaded	15.2 MiB	7.2 MiB
JS heap of 17 workers during playback	257 MiB	117 MiB

Behavior

Lookups by the dynamic linker in workers return the same slots as before. A function that appears in several slots still resolves to its last slot, as the walk did.

The difference is a non-exported main-module function passed to addFunction in a worker. JS can only reach such a function through the table itself (for example with getWasmTableEntry), so it already has its address. Before, the walk found its existing slot. Now, the worker gives it a new slot, so it has a different address there than on the main thread. Keeping the old behavior would need the full walk this PR removes. With ASSERTIONS=2, addFunction already reports this case ("function in Table but not functionsInTableMap"). The limitation is noted in a comment on initFunctionsInTableMap and in the ChangeLog entry.

The main thread still walks the table once. #27993 creates the main module's GOT entries lazily and doesn't change the walk, so the two changes are independent.

Testing

test_pthread_dylink now asserts that a side module sees the same &bar_main as the main module, on the main thread and in a worker. That assertion fails if workers don't add the recorded slots.

Passing: all test_pthread_dl*, test_pthread_dylink* and test_pthread_tls_dylink tests in core0, core2 and wasm64, other.test_dylink_pthread*, and the dylink codesize tests (unchanged).

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request optimizes worker initialization in pthreads builds with MAIN_MODULE by passing only the table slots of the main module's exported functions to workers, rather than having them walk the entire function table. Feedback suggests adding a defensive check in src/lib/libaddfunction.js to ensure getWasmTableEntry(slot) returns a valid object before adding it to the WeakMap, preventing potential runtime crashes in workers.

[clementperon]

@sbc100 is this something you want to merge upstream ?

[sbc100]

Mostly likely yes, I'm just a little review constrained right now.

I'll try to get to it.

[clementperon]

Thank you, take your time and don't hesitate if you want me to perform more test.

[sbc100]

If I'm reading this right it sounds like this means that an address might not represent the same code on all threads? I don't think that can ever work since function pointer can be passed via linear memory and must be callable from all threads.

[clementperon]

Agree I can fix it by having workers scan the main module's table slots once, the first time addFunction misses after startup.

[clementperon]

@sbc100 I have revert it as in practice it never happens.

User code needs this exact pattern to hit it:

1. Get a C function pointer to a non-exported function.
2. In JS, turn it back into a function object with getWasmTableEntry(ptr).
3. In a worker, pass that object to addFunction to get a pointer again.
4. Compare that pointer with one from another thread, or rely on it being the same.