Add workaround for firefox bug. by Kuinox · Pull Request #25 · ktock/qemu-wasm

Kuinox · 2025-05-18T16:38:12Z

There is a firefox bug(or chrome ?), which make the current wasm module creation not working on firefox.
Here is patch that hope to fix that.

Sadly I couldn't make the build toolchain work on my machine, so I couldn't test my changes.

ktock · 2025-05-19T02:51:54Z

@Kuinox Thanks, can you add the DCO signed-off-by line?

Signed-off-by: Nicolas Vandeginste <nvandeginste@gmail.com>

Kuinox · 2025-05-19T14:22:18Z

Done, could you test to see if the change worked on your end ? Like I said on the PR, I have an error while running the build toolchain on my machine (maybe because I'm on windows but it shouldn't cause a problem with docker...)

ktock

Thanks, it seems to work.

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm32/tcg-target.c.inc, QEMU's memory is imorted into the module as "env.buffer", and helper functions are imported as "helper.<id>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [2] as reported by Nicolas Vandeginste in my downstream fork[3]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [3] #25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

ktock · 2025-05-19T15:23:33Z

@Kuinox Thanks for reporting this issue along with the helpful link. I'm currently working on another branch for refactoring & improvement development of QEMU Wasm aiming upstreaming (#26). While I ended up addressing the problem with a different approach after some exploration, by directly creating a Uint8Array from the SharedArrayBuffer subarray without an extra slice() (please see e242a7a), which worked on Firefox 138 in my testing. Still, I appreciate you bringing this up.

Kuinox · 2025-05-19T16:09:35Z

No problem, still need to track how they will resolve https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 so we can avoid an expensive multiple MB array copy in the future.

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm32/tcg-target.c.inc, QEMU's memory is imorted into the module as "env.buffer", and helper functions are imported as "helper.<id>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Note Since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [2] as reported by Nicolas Vandeginste in my downstream fork[3]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [3] #25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm32/tcg-target.c.inc, QEMU's memory is imported into the module as "env.buffer", and helper functions are imported as "helper.<id>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Note Since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [2] as reported by Nicolas Vandeginste in my downstream fork[3]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [3] #25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm32/tcg-target.c.inc, QEMU's memory is imported into the module as "env.buffer", and helper functions are imported as "helper.<id>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Note Since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [2] as reported by Nicolas Vandeginste in my downstream fork[3]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [3] ktock/qemu-wasm#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com> Message-Id: <2433bd9fe6eed2f93f511195cedbfde0fc4a89a4.1747744132.git.ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm32/tcg-target.c.inc, QEMU's memory is imported into the module as "env.buffer", and helper functions are imported as "helper.<id>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Note Since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [2] as reported by Nicolas Vandeginste in my downstream fork[3]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [3] ktock/qemu-wasm#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm32/tcg-target.c.inc, QEMU's memory is imported into the module as "env.buffer", and helper functions are imported as "helper.<id>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Note Since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [2] as reported by Nicolas Vandeginste in my downstream fork[3]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [3] #25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] ktock/qemu-wasm#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com> Message-Id: <2ed7c66cf4fc77e69262486f0c735d747b4dcba1.1755623522.git.ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] ktock/qemu-wasm#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] #25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] ktock/qemu-wasm#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] ktock/qemu-wasm#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com> Message-Id: <c0d05186cd431515eb3f97a7c860ec5b6deac0a5.1756216429.git.ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] ktock/qemu-wasm#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com> Message-Id: <c0d05186cd431515eb3f97a7c860ec5b6deac0a5.1756724464.git.ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] ktock/qemu-wasm#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] ktock#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] #25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm64/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] #25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm64/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] ktock/qemu-wasm#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com> Message-Id: <00b8d87b3e0acf00b140a3f60f91c84eeae95b3b.1769407033.git.ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm64/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] ktock/qemu-wasm#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

instantiate_wasm is a function that instantiates a TB's Wasm binary, importing the functions as specified by its arguments. Following the header definition in wasm64/tcg-target.c.inc, QEMU's memory is imported into the module as "env.memory", and helper functions are imported as "helper.<idx>". The instantiated Wasm module is imported to QEMU using Emscripten's "addFunction" feature[1] which returns a function pointer. This allows QEMU to call this module directly from C code via that pointer. Since the subarray() method doesn't accept a BigInt value which is used for the 64bit pointer value, it is converted to a Number (i53) using bigintToI53Checked method of Emscripten. Although this conversion (64bit to 53bit) drops higher bits, the maximum memory size of the engine implementations is currently limited to 16GiB[2] so we can assume that the pointers are within the Number's range. Note that since FireFox 138, WebAssembly.Module no longer accepts a SharedArrayBuffer as input [3] as reported by Nicolas Vandeginste in my fork[4]. This commit ensures that WebAssembly.Module() is passed a Uint8Array created from the binary data on a SharedArrayBuffer. [1] https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c [2] https://webassembly.github.io/memory64/js-api/#limits [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1965217 [4] ktock#25 Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>

tcg: add workaround for firefox bug.

5bb2e20

Signed-off-by: Nicolas Vandeginste <nvandeginste@gmail.com>

Kuinox force-pushed the master branch from bdbb891 to 5bb2e20 Compare May 19, 2025 14:19

ktock approved these changes May 19, 2025

View reviewed changes

ktock merged commit 8604ed4 into ktock:master May 19, 2025

ktock mentioned this pull request May 21, 2025

Bump up qemu-wasm to the latest container2wasm/container2wasm#471

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add workaround for firefox bug.#25

Add workaround for firefox bug.#25
ktock merged 1 commit intoktock:masterfrom
Kuinox:master

Kuinox commented May 18, 2025 •

edited

Loading

Uh oh!

ktock commented May 19, 2025

Uh oh!

Kuinox commented May 19, 2025 •

edited

Loading

Uh oh!

ktock left a comment

Uh oh!

ktock commented May 19, 2025

Uh oh!

Kuinox commented May 19, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Kuinox commented May 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ktock commented May 19, 2025

Uh oh!

Kuinox commented May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ktock left a comment

Choose a reason for hiding this comment

Uh oh!

ktock commented May 19, 2025

Uh oh!

Kuinox commented May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Kuinox commented May 18, 2025 •

edited

Loading

Kuinox commented May 19, 2025 •

edited

Loading

Kuinox commented May 19, 2025 •

edited

Loading