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? |
|
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. |
|
@sbc100 do you have any specific feedback on this PR? |
It feel like a lot of complexity to be adding. Perhaps we can find way to reduce it somehow? I need to take a deeper look at some point. |
|
Unfortunately, I don't think we can do anything much simpler than this unless we change the shared object files. |
|
@sbc100 would you mind looking into this when you have a chance? It would be nice to make dynamic linking work correctly with JSPI. |
This is an automatic change generated by tools/maint/rebaseline_tests.py. The following (2) test expectation files were updated by running the tests with `--rebaseline`: ``` other/codesize/test_codesize_hello_dylink.gzsize: 5860 => 5869 [+9 bytes / +0.15%] other/codesize/test_codesize_hello_dylink.jssize: 12839 => 12877 [+38 bytes / +0.30%] Average change: +0.22% (+0.15% - +0.30%) ```
|
@sbc100 I think this is ready for another round of review when you have a chance. |
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.