On some platforms, gdb provides a special process record and replay target that can record a log of the process execution, and replay it later with both forward and reverse execution commands.
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.
If the record for the next instruction is not in the execution log, gdb will debug in record mode. In this mode, the inferior executes normally, and gdb records the execution log for future replay.
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.
For architecture environments that support process record and replay, gdb provides the following commands:
record methodfull recording method. The following
recording methods are available:
fullbtrace formatrecord stop.
The recording format can be specified as parameter. Without a parameter the command chooses the recording format. The following recording formats are available:
btsptThe trace can be recorded with very low overhead. The compressed trace format also allows small trace buffers to already contain a big number of instructions compared to BTS.
Decoding the recorded execution trace, on the other hand, is more expensive than decoding BTS trace. This is mostly due to the increased number of instructions to process. You should increase the buffer-size with care.
Not all recording formats may be available on all processors.
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 record method command.
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), not
all recording methods are available. The full recording method
does not support these two modes.
record stopWhen 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.
record gotorecord goto beginrecord goto startrecord goto endrecord goto nrecord save filenameThis command may not be available for all recording methods.
record restore filenamerecord save.
set record full insn-number-max limitset record full insn-number-max unlimitedfull
recording method. 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-limit option, described below.)
If limit is unlimited or zero, gdb will never
delete recorded instructions from the execution log. The number of
recorded instructions is limited only by the available memory.
show record full insn-number-maxfull
recording method.
set record full stop-at-limitfull recording method 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 full stop-at-limitstop-at-limit.
set record full memory-queryfull recording method.
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 full memory-querymemory-query.
The btrace record target does not trace data. As a
convenience, when replaying, gdb reads read-only memory off
the live program directly, assuming that the addresses of the
read-only areas don't change. This for example makes it possible to
disassemble code while replaying, but not to print variables.
In some cases, being able to inspect variables might be useful.
You can use the following command for that:
set record btrace replay-memory-accessbtrace recording method when
accessing memory during replay. If read-only (the default),
gdb will only allow accesses to read-only memory.
If read-write, gdb will allow accesses to read-only
and to read-write memory. Beware that the accessed memory corresponds
to the live target and not necessarily to the current replay
position.
set record btrace cpu identifierProcessor errata are defects in processor operation, caused by its design or manufacture. They can cause a trace not to match the specification. This, in turn, may cause trace decode to fail. gdb can detect erroneous trace packets and correct them, thus avoiding the decoding failures. These corrections are known as errata workarounds, and are enabled based on the processor on which the trace was recorded.
By default, gdb attempts to detect the processor automatically, and apply the necessary workarounds for it. However, you may need to specify the processor if gdb does not yet support it. This command allows you to do that, and also allows to disable the workarounds.
The argument identifier identifies the cpu and is of the
form: vendor:procesor identifier. In addition,
there are two special identifiers, none and auto
(default).
The following vendor identifiers and corresponding processor identifiers are currently supported:
intel
| family/model[/stepping]
|
On GNU/Linux systems, the processor family, model, and
stepping can be obtained from /proc/cpuinfo.
If identifier is auto, enable errata workarounds for the
processor on which the trace was recorded. If identifier is
none, errata workarounds are disabled.
For example, when using an old gdb on a new system, decode may fail because gdb does not support the new processor. It often suffices to specify an older processor that gdb supports.
(gdb) info record
Active record target: record-btrace
Recording format: Intel Processor Trace.
Buffer size: 16kB.
Failed to configure the Intel Processor Trace decoder: unknown cpu.
(gdb) set record btrace cpu intel:6/158
(gdb) info record
Active record target: record-btrace
Recording format: Intel Processor Trace.
Buffer size: 16kB.
Recorded 84872 instructions in 3189 functions (0 gaps) for thread 1 (...).
show record btrace replay-memory-accessreplay-memory-access.
show record btrace cpuset record btrace bts buffer-size sizeset record btrace bts buffer-size unlimitedIf size is a positive number, then gdb will try to
allocate a buffer of at least size bytes for each new thread
that uses the btrace recording method and the BTS format.
The actually obtained buffer size may differ from the requested
size. Use the info record command to see the actual
buffer size for each thread that uses the btrace recording method and
the BTS format.
If limit is unlimited or zero, gdb will try to
allocate a buffer of 4MB.
Bigger buffers mean longer traces. On the other hand, gdb will
also need longer to process the branch trace data before it can be used.
show record btrace bts buffer-size sizeset record btrace pt buffer-size sizeset record btrace pt buffer-size unlimitedIf size is a positive number, then gdb will try to
allocate a buffer of at least size bytes for each new thread
that uses the btrace recording method and the Intel Processor Trace
format. The actually obtained buffer size may differ from the
requested size. Use the info record command to see the
actual buffer size for each thread.
If limit is unlimited or zero, gdb will try to
allocate a buffer of 4MB.
Bigger buffers mean longer traces. On the other hand, gdb will
also need longer to process the branch trace data before it can be used.
show record btrace pt buffer-size sizeinfo recordfullfull recording method, it shows the state of process
record and its in-memory execution log buffer, including:
btracebtrace recording method, it shows:
For the bts recording format, it also shows:
For the pt recording format, it also shows:
record deleterecord instruction-historyset record instruction-history-size command. Instructions
are printed in execution order.
It can also print mixed source+disassembly if you specify the the
/m or /s modifier, and print the raw instructions in hex
as well as in symbolic form by specifying the /r modifier.
The current position marker is printed for the instruction at the
current program counter value. This instruction can appear multiple
times in the trace and the current position marker will be printed
every time. To omit the current position marker, specify the
/p modifier.
To better align the printed instructions when the trace contains
instructions from more than one function, the function name may be
omitted by specifying the /f modifier.
Speculatively executed instructions are prefixed with ‘?’. This feature is not available for all recording formats.
There are several ways to specify what part of the execution log to disassemble:
record instruction-history insnrecord instruction-history insn, +/-n+, disassembles
n instructions after instruction number insn. If
n is preceded with -, disassembles n
instructions before instruction number insn.
record instruction-historyrecord instruction-history -record instruction-history begin, endThis command may not be available for all recording methods.
set record instruction-history-size sizeset record instruction-history-size unlimitedrecord
instruction-history command. The default value is 10.
A size of unlimited means unlimited instructions.
show record instruction-history-sizerecord
instruction-history command.
record function-call-history/l modifier is
specified), and the instructions numbers that form the sequence (if
the /i modifier is specified). The function names are indented
to reflect the call stack depth if the /c modifier is
specified. The /l, /i, and /c modifiers can be
given together.
(gdb) list 1, 10
1 void foo (void)
2 {
3 }
4
5 void bar (void)
6 {
7 ...
8 foo ();
9 ...
10 }
(gdb) record function-call-history /ilc
1 bar inst 1,4 at foo.c:6,8
2 foo inst 5,10 at foo.c:2,3
3 bar inst 11,13 at foo.c:9,10
By default, ten lines are printed. This can be changed using the
set record function-call-history-size command. Functions are
printed in execution order. There are several ways to specify what
to print:
record function-call-history funcrecord function-call-history func, +/-n+, prints n functions after
function number func. If n is preceded with -,
prints n functions before function number func.
record function-call-historyrecord function-call-history -record function-call-history begin, endThis command may not be available for all recording methods.
set record function-call-history-size sizeset record function-call-history-size unlimitedrecord function-call-history command. The default value is 10.
A size of unlimited means unlimited lines.
show record function-call-history-sizerecord function-call-history command.