Use wasmImports as the single global symbol table for dynamic linking#18540
Conversation
df7040b to
7af37d7
Compare
asmLibraryArg as the single global symbol table for dynamic linkingwasmImports as the single global symbol table for dynamic linking
6ca3011 to
2794cfa
Compare
5a022f5 to
51cce5d
Compare
41fb296 to
f5b3266
Compare
f5b3266 to
9d2f486
Compare
| // wasmImports for as-yet-undefined symbols doesn't work since ASYNCIFY then | ||
| // wraps these stub functions and we can't then replace them directly. Instead | ||
| // the stub functions call into `asyncifyStubs` which gets populated by the | ||
| // dyanmic linker and symbols are loaded. |
There was a problem hiding this comment.
Which functions end up here? I thought all of them, initially, but reading other code I am not sure.
There was a problem hiding this comment.
That is, one place seems to always read from asyncifyStubs, but another place checks if a thing is there or not, so I am confused.
There was a problem hiding this comment.
Only functions for which we create stubs need to appear in this map. Its the same set of functions that get the .stub attribute set up them. These are functions which are required to instantiate the main module, but which are provided later, by a side module.
Without ASYNCIFY we simply replace the existing .stub function wasmImports once the symbols gets resolved.
With ASYNCIFY this appraoch doesn't work because the thing in the wasmImports dict might be an asyncify wrapper around the .stub we created. In this case we replace the entry in asyncifyStubs which is called by the stub function.
There was a problem hiding this comment.
There are two places the asyncifyStubs are used.
- In the stub functions themselves. In debug builds we assert that that right entry is present. In release builds we will just trap if its not present.
- In the dynamic linker: When a new symbol is loaded it replaces the entry in asyncifyStubs, but only if that key already exists in the dictionary.
Previously we were looking up symbols on the `Module` object which meant building with `EXPORT_ALL` and exporting all symbols there. This change adds all needed symbols to the `wasmImports` maps and uses that as the single source for symbol lookups. This is split out from my work on #18376. This should be a code size win in for most users of dynamic linking. It also avoids extra symbols being present on the `Module` object that the user didn't ask for.
9d2f486 to
f7e4555
Compare
kripken
left a comment
There was a problem hiding this comment.
Thanks, that's what I was missing. Code makes sense to me now...
Previously we were looking up symbols on the
Moduleobject which meant building withEXPORT_ALLand exporting all symbols there. This change adds all needed symbols to thewasmImportsmap and uses that as the single source for symbol lookups.This is split out from my work on #18376.
This should be a code size win for most users of dynamic linking. It also avoids extra symbols being present on the
Moduleobject that the user didn't ask for.