Differences between revisions 7 and 8
Revision 7 as of 2009-10-15 04:59:18
Size: 4983
Editor: 75-101-1-32
Comment: links
Revision 8 as of 2009-10-15 07:30:45
Size: 5064
Editor: 61
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Process record and replay is a gdb feature first appearing in the [[GDB_7.0_Release|gdb 7.0 release]] (September 2009).
Line 3: Line 4:
Process record and replay is a gdb feature first appearing in the
[[GDB_7.0_Release | gdb 7.0 release]] (September 2009).
For supported architectures and OS/ABIs, this feature allows the user to record the execution of a program being debugged by gdb, and then "play back" the recorded execution, deterministicly and repeatedly if desired.
Line 6: Line 6:
For supported architectures and OS/ABIs, this feature allows the user to record the execution
of a program being debugged by gdb, and then "play back" the recorded execution, deterministicly
and repeatedly if desired.

Process record and replay also supports gdb's [[ReverseDebug | reverse debugging]] commands,
so that during replay it is possible to debug the program backward as well as forward.
Process record and replay also supports gdb's [[ReverseDebug|reverse debugging]] commands, so that during replay it is possible to debug the program backward as well as forward.
Line 14: Line 9:
Line 22: Line 16:

Process record and replay works by logging the execution of each machine instruction
in the child process (the program being debugged), together with each corresponding
change in machine state (the values of memory and registers). By successively "undoing"
each change in machine state, in reverse order, it is possible to revert the state of
the program to an arbitrary point earlier in the execution. Then, by "redoing" the
changes in the original order, the program state can be moved forward again.
Process record and replay works by logging the execution of each machine instruction in the child process (the program being debugged), together with each corresponding change in machine state (the values of memory and registers). By successively "undoing" each change in machine state, in reverse order, it is possible to revert the state of the program to an arbitrary point earlier in the execution. Then, by "redoing" the changes in the original order, the program state can be moved forward again.
Line 31: Line 19:
Line 36: Line 23:
Start process record/replay (ie. start recording the subsequent execution of the
child process). You must start debugging the program (with the "run" command)
before using this command to start recording. You can start recording at any
point after the child process has been started (eg. at a breakpoint).
Start process record/replay (ie. start recording the subsequent execution of the child process). You must start debugging the program (with the "run" command) before using this command to start recording. You can start recording at any point after the child process has been started (eg. at a breakpoint).
Line 43: Line 27:
Stop process record/replay (ie. cease recording the program execution), and
discard any existing execution log. The child process is '''not''' terminated,
and you may continue to debug it normally.
Stop process record/replay (ie. cease recording the program execution), and discard any existing execution log. The child process is '''not''' terminated, and you may continue to debug it normally.
Line 57: Line 39:
Controls the behavior when the buffer becomes full. If "on", gdb will stop and ask the user
what to do. If "off", the buffer acts as a circular buffer, deleting the oldest records to
make room for new ones. Default is "on".
Controls the behavior when the buffer becomes full. If "on", gdb will stop and ask the user what to do. If "off", the buffer acts as a circular buffer, deleting the oldest records to make room for new ones. Default is "on".
Line 66: Line 46:
To run the gdb reverse-debugging tests with process record and replay, you need a board description file "precord.exp", which should look like this:
Line 67: Line 48:
To run the gdb reverse-debugging tests with process record and replay,
you need a board description file "precord.exp", which should look like this:
Line 75: Line 54:
Then the "make check" command will look like this:
Line 76: Line 56:
Then the "make check" command will look like this:
Line 80: Line 59:
Line 95: Line 73:
See the more extensive [[ProcessRecord/WishList|WishList here]].
Line 96: Line 75:
See the more extensive [[ProcessRecord/WishList | WishList here]]. See the old to do list (it include some links of patch) [[javascript:void(0);/*1255592211694*/|here]].
Line 99: Line 78:
support for the basic floating point instructions. We would like to also add support for the
more modern math coprocessors (mmx etc.)

support for the basic floating point instructions. We would like to also add support for the more modern math coprocessors (mmx etc.)
Line 110: Line 89:
 1. Improve performance (speed and memory usage).   1. Improve performance (speed and memory usage).
Line 118: Line 97:
What I think is still missing from the manual is a few sentences that would explain when this target is useful. Can you provide such warstories? I will then add them to the manual. No, I mean description of when this target is useful in real life, and'' how you will use it. In other words, put yourself in a place of someone who reads the manual about the record/replay target and asks him/herself "why should I care about this new feature?" Then try to answer that question. And try to answer it so that the reader will wonder how could she ever get by without this feature before. What I think is still missing from the manual is a few sentences that would explain when this target is useful. Can you provide such warstories? I will then add them to the manual. No, I mean description of when this target is useful in real life, and'' how you will use it. In other words, put yourself in a place of someone who reads the manual about the record/replay target and asks him/herself "why should I care about this new feature?" Then try to answer that question. And try to answer it so that the reader will wonder how could she ever get by without this feature before. ''
Line 120: Line 99:
There is a contribution from Marc Khouzam at http://sourceware.org/ml/gdb-patches/2009-05/msg00058.html.

''There is a contribution from Marc Khouzam at http://sourceware.org/ml/gdb-patches/2009-05/msg00058.html. ''
Line 125: Line 102:
CategoryHomepage '' CategoryHomepage ''

Process Record and Replay

Process record and replay is a gdb feature first appearing in the gdb 7.0 release (September 2009).

For supported architectures and OS/ABIs, this feature allows the user to record the execution of a program being debugged by gdb, and then "play back" the recorded execution, deterministicly and repeatedly if desired.

Process record and replay also supports gdb's reverse debugging commands, so that during replay it is possible to debug the program backward as well as forward.

Supported Targets

Process record and replay is currently supported for the following gdb targets:

  • i386-linux
  • amd64-linux
  • moxie-elf / moxie-linux

How it works

Process record and replay works by logging the execution of each machine instruction in the child process (the program being debugged), together with each corresponding change in machine state (the values of memory and registers). By successively "undoing" each change in machine state, in reverse order, it is possible to revert the state of the program to an arbitrary point earlier in the execution. Then, by "redoing" the changes in the original order, the program state can be moved forward again.

User commands

The following gdb commands are defined for process record / replay:

  • "target record" (or simply "record", for short)

Start process record/replay (ie. start recording the subsequent execution of the child process). You must start debugging the program (with the "run" command) before using this command to start recording. You can start recording at any point after the child process has been started (eg. at a breakpoint).

  • "record stop"

Stop process record/replay (ie. cease recording the program execution), and discard any existing execution log. The child process is not terminated, and you may continue to debug it normally.

  • "record delete"

Discard the existing execution log, and begin recording a new log.

  • "set record insn-number-max"

Set the maximum number of instruction executions that will be recorded (ie. the size of the process record log buffer). Zero means unlimited. Default is 200,000.

  • "set record stop-at-limit"

Controls the behavior when the buffer becomes full. If "on", gdb will stop and ask the user what to do. If "off", the buffer acts as a circular buffer, deleting the oldest records to make room for new ones. Default is "on".

  • "info record insn-number"

Show the current number of instructions in the record/replay buffer.

Testing

To run the gdb reverse-debugging tests with process record and replay, you need a board description file "precord.exp", which should look like this:

# Testing programs using process record/replay (precord)
load_base_board_description "unix"
set_board_info gdb,can_reverse 1
set_board_info gdb,use_precord 1

Then the "make check" command will look like this:

make check RUNTESTFLAGS="--target_board precord (test file or files)

At the time of this writing, the reverse debugging tests include:

  • break-reverse.exp
  • consecutive-reverse.exp
  • finish-reverse.exp
  • i386-reverse.exp
  • machinestate.exp
  • sigall-reverse.exp
  • solib-reverse.exp
  • step-reverse.exp
  • until-reverse.exp
  • watch-reverse.exp

To Do List

See the more extensive WishList here.

See the old to do list (it include some links of patch) here.

  1. Improve support for intel architectures. There is a patch awaiting approval that will add

support for the basic floating point instructions. We would like to also add support for the more modern math coprocessors (mmx etc.)

  1. Add support for more processor architectures (mips, arm etc.)
  2. Add support for more os/abis (currently only linux is supported).
  3. Improve support for memory free (sys_brk).
  4. Improve support for multi-thread and multi-process record/replay.
  5. Improve performance (speed and memory usage).
  6. Save execution log to a file, and restore it later for replay.
  7. Add more test cases to the testsuite.
  8. Improve documentation. The following is a quote from Eli Zaretskii, the gdb docs maintainer:

What I think is still missing from the manual is a few sentences that would explain when this target is useful. Can you provide such warstories? I will then add them to the manual. No, I mean description of when this target is useful in real life, and how you will use it. In other words, put yourself in a place of someone who reads the manual about the record/replay target and asks him/herself "why should I care about this new feature?" Then try to answer that question. And try to answer it so that the reader will wonder how could she ever get by without this feature before.

There is a contribution from Marc Khouzam at http://sourceware.org/ml/gdb-patches/2009-05/msg00058.html.


CategoryHomepage

None: ProcessRecord (last edited 2013-06-17 17:33:39 by TomTromey)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.