shared memory: enable shared memory in differential_v8 fuzz target

[abrown]

In the differential_v8 fuzz target, the oracle retrieves the first exported memory and checks that the memory contents are the same between Wasmtime and V8. To properly enable shared memory in this fuzz target, we would need to check whether the first exported memory is shared and if so:

• use get_shared_memory() instead of get_memory() in the Wasmtime API
• use SharedArrayBuffer instead of ArrayBuffer in the V8 API

[cfallin]

As a high-level question: how are we planning to do differential checking in the presence of nondeterminism if/when our generated fuzz tests include actual spawning of multiple threads?

I can see a few possibilities:

• We only ever fuzz single-threaded programs that happen to use shared memory primitives. Definitely better than nothing, but not a super-strong claim to a robust implementation on its own, I guess?
• We somehow try to enforce the same interleavings (nondeterministic choices in the memory model) between differential oracle and execution-under-test. Also seems difficult, implies heavy instrumentation (Valgrind-style)...
• We generate test programs in a way that, by construction, ensures determinism. I'm not sure exactly what this would look like but it seems like the least bad of the options: basically we have some framework/skeleton of generated program into which wasm-smith plugs arbitrary code, but the overall framework is designed to not have data races, etc (parallel loop or somesuch).
• Something else?

[alexcrichton]

Personally I have no ideas beyond your first bullet. I don't know how to fuzz a multithreaded system for correctness really other than custom one-off programs which we can verify that "when compiled to wasm and run this should always work".