Can we record the instructions given to the cpu?

Question

Given an initial state of a user driven program in memory, can we record the instructions given to the cpu, reload the program to it's initial state and playback the cpu instructions and have the program run as it did when the user was using it, without the user there?

I'm sorry if this question is badly written, or confusing.

Answer 1

If the user did interact with the program and you didn't store the history of inputs (or other form of interactions), the answer is clearly no.

A complete execution trace can be huge (1 Giga instructions per second...)

Answer 2

Most likely! It is possible to step through a program in a debugger going instruction by instruction. You'd have to also record the instructions in some form as well, though the program source or executable might work just as well.

Some programs like to store things like networking logs or action logs in order to store the state of the program at some point in time. Databases may also store important information that can also be looked over when a program "fails." Something as simple as a log can be useful for recording input to a program.

For stepping through instructions, you should be able to use the nexti and stepi commands in GDB in order to execute instruction by instruction. We can also use disassemble to get the assembly instructions that should match-up pretty well with the individual CPU instructions. There should also be analogs in LLDB and MSVC's debugger.

And now, for my example of "state of a user-driven program in memory:"

It's the Windows Blue Screen of Death, but we can see that Windows actually creates a physical memory dump and also uses a debugger for the kernel.

It can be assumed that the physical memory dump can be used to figure out problems with the system at that moment in time and what caused the operating system to crash.

As for recording the individual instructions, the program executable itself should be sufficient to record what exactly happened, as a program's path of execution is clearly defined by the functions and operations it uses. Unless you're using using some sort of runtime meta-programming where you write your execution code at runtime, things should be able to be analyzed. And, even if you do write execution code at runtime, it should still be able to be extracted from a good memory dump, perhaps from inside a sandboxed-environment or through a meta-program to extract the state of the failed program.

Related: http://www.unknownroad.com/rtfm/gdbtut/gdbadvanced.html#STEPI