1481007 - Web Replay: Support WebAssembly

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Web Replay, enhancement)

Description

[Brian Hackett [Laid off!]]

Tasks here include getting the SEGV handlers used for wasm to interoperate with the handlers used for memory snapshots (or just invalidating the recording if OOB accesses occur, like we do with overrecursion exceptions and OOM), updating the progress counter as wasm code runs, and allowing inspecting wasm state via the replay debugger (maybe this would be done as followup or a dependent bug).

Comment 1

[Jason Laster [:jlast]]

Adding some notes from slack

wasm support just needs a way to coordinate with the exception trapping that is done to handle out of bounds accesses in wasm
we need to coordinate because we have our own exception trapping mechanism that is used for keeping track of the memory modified between checkpoints the simple thing to do would be to just ban out of bounds accesses when recording, and then when replaying the wasm trap should never be hit. 

There might be a few other minor things to fix as well. 

By banning, we would invalidate the recording if an out of bounds access occurred while recording

(which, with the current implementation, would immediately crash the tab)

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

To wit: it's more general than just out-of-bounds errors; any errors occurring in wasm code (e.g. conversions from floating-point to integers when passed NaNs, or outside the integer's range) will cause a hardware trap. Stack overflow / interrupt checks use the trapping mechanism too, and might be needed even if the program isn't raising software exceptions.

Comment 3

[Brian Hackett [Laid off!]]

(In reply to Benjamin Bouvier [:bbouvier] from comment #2)
> To wit: it's more general than just out-of-bounds errors; any errors
> occurring in wasm code (e.g. conversions from floating-point to integers
> when passed NaNs, or outside the integer's range) will cause a hardware
> trap. Stack overflow / interrupt checks use the trapping mechanism too, and
> might be needed even if the program isn't raising software exceptions.

OK, thanks.  During normal execution we can't record/replay stack overflows or interrupt checks in any case --- stack overflows will invalidate the recording (which will immediately crash in the current implementation), and the mechanisms for interrupting running JS code are disabled.