Fix late-binding symbols with JSPI #23619
Conversation
hoodmane
requested review from
brendandahl and
sbc100
and removed request for
brendandahl
hoodmane
force-pushed
the
jspi-dylink-stubs
branch
4 times, most recently
from
55ff7e0 to
33707ea
Compare
Late-binding symbols get a JS stub import that resolves the symbol and then makes an onward call. This breaks JSPI. (It also canonicalizes NaNs by round tripping them through JS). To fix this, we have to walk the import table and make wasm module stubs for each of the missing function-type symbols. These stubs will call a JS function to resolve the symbol but then insert it into a table and return control back to the wasm stub which has to make the onward call. This currently relies on --experimental-wasm-type-reflection. To avoid that, we need to parse the import table of the wasm binary manually. Also, without wasm-type-reflection, we have no way to handle the case where someone calls `loadWebAssemblyModule()` on a WebAssembly module instead of a Uint8Array.
hoodmane
force-pushed
the
jspi-dylink-stubs
branch
from
33707ea to
ed49619
Compare
Why do you say this? Is that simply because wasm type reflection is not standardized yet? Presumably if it was standardized this would be good tool to solve this problem? |
| return WebAssembly.instantiate(binary, info).then( | ||
| (result) => postInstantiation(result.module, result.instance) | ||
| ); | ||
| return (async function() { |
There was a problem hiding this comment.
Hmm.. nice trick to use await inside a function that is not async..
| sig += lookup[v]; | ||
| } | ||
| return sig; | ||
| }, |
There was a problem hiding this comment.
Can any of this new code be shared with the existing code for binary module creation in in libraryadd_function.js?
There was a problem hiding this comment.
Perhaps it would make sense to factor out the wasm prelude (magic + version) as an export from libaddfunction. Other than that, the only code that's really shared is generateFuncType which we already extracted as a separate function.
There was a problem hiding this comment.
wasmSigToEmscripten is the inverse function of sigToWasmTypes in libaddfunction.js. In Pyodide I have a runtime_wasmfile for producing wasm trampolines like this:
https://github.com/pyodide/pyodide/blob/main/src/core/stack_switching/runtime_wasm.mjs
I could eventually upstream a bit more of this. It's not great for code size if we only have a few trampolines but it certainly leads to more readable code. Here's an example where I make invoke_sig functions with it:
https://github.com/pyodide/pyodide/blob/main/src/core/stack_switching/create_invokes.mjs
I think I might copy this code into libffi because I've been intending to make libffi compatible with stack switching.
|
Yes in particular my concern is that I expect jspi to become available without a feature flag before wasm-type-reflection so if we depend on it there will be engines that otherwise would be able to use our jspi but can't because they haven't yet shipped type reflection.
Absolutely it's the right tool. |
Late-binding symbols get a JS stub import that resolves the symbol and then makes an onward call. This breaks JSPI. (It also canonicalizes NaNs by round tripping them through JS).
To fix this, we have to walk the import table and make wasm module stubs for each of the missing function-type symbols. These stubs will call a JS function to resolve the symbol but then insert it into a table and return control back to the wasm stub which has to make the onward call.
This currently relies on --experimental-wasm-type-reflection. To avoid that, we will need to parse the import table of the wasm binary manually. Also, without wasm-type-reflection, we have no way to handle the case where someone calls
loadWebAssemblyModule()on a WebAssembly module instead of a Uint8Array.This half way fixes #23395. I say half way because to be truly fixed the solution shouldn't rely on wasm type reflection. See also #23600.