A curious and useful feature of GDB is process recording, allowing an analyst to step forwards and backwards through execution, writing a continuous log of the changes to program state that allow for remarkably accurate playback of program code.
Although we can all safely say the process recording log contains the executable's changes to the various data and control registers, the functionality is much more than keeping some serialized representation of the current continuation. For example, I've been able to reify the state of an executable that uses threads to modify shared memory.
Certainly we can't expect time dependent code to work, but if threading code modifying shared state can, in general, be stepped through backwards and still work reliably again, what limitations does process recording have beyond the purely architectural challenges (i.e displaced stepping) specified in the documentation?
