Is there any reason to believe that this will be faster or more powerful than how reverse debugging works today? rr is already pretty fantastic and handles pretty complex cases surprisingly well with decent performance. I believe the way it works is that it only records memory changes of side-effect APIs (I.e. I/O, kernel, etc) & then just runs the program instruction backwards between those points. I’m not sure that snapshotting the entire RAM for an application will prove to be more efficient/powerful (copying large amounts of RAM is generally expensive). You might try to do crazy tricks like making the pages COW (while flushing them to disk) to reduce the actual cost of how many pages need to be copied. I think that’s still tough to compete with vs just recording the little bit of state around function calls that have side effects.
I've contemplated building a reverse debugger for wasm - rr is amazing, but frustrates me with touchy dependence on hardware features (sometimes doesn't work in a VM, doesn't support some CPUs, etc) and lack of ability to fork the timeline. I'd love to be able to backup, change a variable, and then proceed forwards - tree style undo and redo, as it were.
I haven’t tried but I’m pretty sure you can change variable values. Aside from it being Linux-only I haven’t encountered the CPU challenges. VM incompatibilities are a different story as I generally only ever run directly on metals when debugging. That being said, it looks like it does work (at least if you have sufficiently new software bits) so may be worth giving it another go: https://github.com/rr-debugger/rr/issues/2806
Sorry, this issue is what I was referring to as what I would like to be able to do: https://github.com/rr-debugger/rr/issues/1622
I might have been too down on rr, it is a very cool tool! Wasm doesn't have great debugging support right now, so I was thinking of a way to fix that and get the features I wanted out of rr in one swoop.
Changing a variable and resuming execution isn't the hard part. The hard part is what happens when the resumed execution wants to, e.g., read from a socket. That socket doesn't exist in the replay. What would you do?
