You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently (as of commit 164835e), after code generation is finished and before execution from the newly generated code starts on AArch64, both cranelift-jit and wasmtime-jit do not perform any actions other than making the code buffers readable and executable instead of readable and writable. In particular, they skip all the actions prescribed by the Arm Architecture Reference Manual in sections B2.2.5 and B.2.4.4. On Linux from C code, for example, it is sufficient to perform a call to the __builtin___clear_cache() function on the code buffers and, if we are in a multi-threaded environment (which is the case for Wasmtime), another call to membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE, 0).
This issue has already been discussed on Zulip, and potentially would affect other architectures with weak memory models (and non-coherent data and instruction caches in particular).
The text was updated successfully, but these errors were encountered:
akirilov-arm
added
bug
Incorrect behavior in the current implementation that needs fixing
wasmtime
Issues about wasmtime that don't fall into another label
labels
Sep 10, 2021
With #3355, Wasmtime now uses rsix for some of its system calls. I added a membarrier API to rsix 0.23.2, so this can now be implemented using the rsix::process::membarrier function.
Currently (as of commit 164835e), after code generation is finished and before execution from the newly generated code starts on AArch64, both
cranelift-jit
andwasmtime-jit
do not perform any actions other than making the code buffers readable and executable instead of readable and writable. In particular, they skip all the actions prescribed by the Arm Architecture Reference Manual in sections B2.2.5 and B.2.4.4. On Linux from C code, for example, it is sufficient to perform a call to the__builtin___clear_cache()
function on the code buffers and, if we are in a multi-threaded environment (which is the case for Wasmtime), another call tomembarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE, 0)
.This issue has already been discussed on Zulip, and potentially would affect other architectures with weak memory models (and non-coherent data and instruction caches in particular).
The text was updated successfully, but these errors were encountered: