7 Recording Inferior's Execution and Replaying It
When this target is in use, if the execution log includes the record for the next instruction, gdb will debug in replay mode. In the replay mode, the inferior does not really execute code instructions. Instead, all the events that normally happen during code execution are taken from the execution log. While code is not really executed in replay mode, the values of registers (including the program counter register) and the memory of the inferior are still changed as they normally would. Their contents are taken from the execution log.
The process record and replay target supports reverse execution (see Reverse Execution), even if the platform on which the inferior runs does not. However, the reverse execution is limited in this case by the range of the instructions recorded in the execution log. In other words, reverse execution on platforms that don't support it directly can only be done in the replay mode.
When debugging in the reverse direction, gdb will work in replay mode as long as the execution log includes the record for the previous instruction; otherwise, it will work in record mode, if the platform supports reverse execution, or stop if not.
- This command starts the process record and replay target. The process
record and replay target can only debug a process that is already
running. Therefore, you need first to start the process with the
run or start commands, and then start the recording with
the target record command.
recare aliases of
Displaced stepping (see displaced stepping) will be automatically disabled when process record and replay target is started. That's because the process record and replay target doesn't support displaced stepping.
If the inferior is in the non-stop mode (see Non-Stop Mode) or in the asynchronous execution mode (see Background Execution), the process record and replay target cannot be started because it doesn't support these two modes.
- Stop the process record and replay target. When process record and
replay target stops, the entire execution log will be deleted and the
inferior will either be terminated, or will remain in its final state.
When you stop the process record and replay target in record mode (at the end of the execution log), the inferior will be stopped at the next instruction that would have been recorded. In other words, if you record for a while and then stop recording, the inferior process will be left in the same state as if the recording never happened.
On the other hand, if the process record and replay target is stopped while in replay mode (that is, not at the end of the execution log, but at some earlier point), the inferior process will become “live” at that earlier state, and it will then be possible to continue the usual “live” debugging of the process from that state.
When the inferior process exits, or gdb detaches from it, process record and replay target will automatically stop itself.
- Save the execution log to a file filename. Default filename is gdb_record.process_id, where process_id is the process ID of the inferior.
- Restore the execution log from a file filename.
File must have been created with
set record insn-number-maxlimit
- Set the limit of instructions to be recorded. Default value is 200000.
If limit is a positive number, then gdb will start deleting instructions from the log once the number of the record instructions becomes greater than limit. For every new recorded instruction, gdb will delete the earliest recorded instruction to keep the number of recorded instructions at the limit. (Since deleting recorded instructions loses information, gdb lets you control what happens when the limit is reached, by means of the
stop-at-limitoption, described below.)
If limit is zero, gdb will never delete recorded instructions from the execution log. The number of recorded instructions is unlimited in this case.
show record insn-number-max
- Show the limit of instructions to be recorded.
set record stop-at-limit
- Control the behavior when the number of recorded instructions reaches
the limit. If ON (the default), gdb will stop when the limit
is reached for the first time and ask you whether you want to stop the
inferior or continue running it and recording the execution log. If
you decide to continue recording, each new recorded instruction will
cause the oldest one to be deleted.
If this option is OFF, gdb will automatically delete the oldest record to make room for each new one, without asking.
show record stop-at-limit
- Show the current setting of
set record memory-query
- Control the behavior when gdb is unable to record memory
changes caused by an instruction. If ON, gdb will query
whether to stop the inferior in that case.
If this option is OFF (the default), gdb will automatically ignore the effect of such instructions on memory. Later, when gdb replays this execution log, it will mark the log of this instruction as not accessible, and it will not affect the replay results.
show record memory-query
- Show the current setting of
- Show various statistics about the state of process record and its
in-memory execution log buffer, including:
- Whether in record mode or replay mode.
- Lowest recorded instruction number (counting from when the current execution log started recording instructions).
- Highest recorded instruction number.
- Current instruction about to be replayed (if in replay mode).
- Number of instructions contained in the execution log.
- Maximum number of instructions that may be contained in the execution log.
- When record target runs in replay mode (“in the past”), delete the subsequent execution log and begin to record a new execution log starting from the current address. This means you will abandon the previously recorded “future” and begin recording a new “future”.