[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, before updateGOT, and passes them to workers in the load message next to sharedModules. A worker adds just those slots to its map, plus anything beyond the main module's initial table (side modules, later addFunction slots).

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 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.
• A JS function that addFunction wrapped is still found through the entry addFunction records.

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). 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 in getFunctionAddress 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.

test_pthread_dylink also has a new assertions2 variant that builds with -sASSERTIONS=2. In that mode, addFunction checks that every function already in the table is also in functionsInTableMap. With the worker loop over the recorded slots removed, this variant aborts in the worker with that message.

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). test_pthread_dylink_assertions2 passes in core0, core2 and wasm64.

🤖 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.