A Wish List for Fixes and Features for Process Record

In no particular order...

Feature is in gdb now, to dump an execution log (together with a core file image) into a modified core file that can be loaded and debugged again later.

Software watchpoints already work with process record, but if you set a hardware watchpoint, gdb silently accepts it but will not stop for it.

There has been some discussion on the mailing list about a generic "bookmark" feature for all record/replay targets (eg. Simics, VMware, UndoDB, process record). The idea is similar to a checkpoint: we could set a bookmark at any execution point in the recording, and then tell gdb to return to that execution point later.

It would be easy to implement this for process record, and then generalize it for remote targets.

Msnyder's working premise is that gdb would maintain a list of bookmarks, very similar to the current list of breakpoints, and that there will be a target-specific method for gdb to request that the target provide a small "token" or piece of data that the target can later use to identify the execution point. For process record, this could be just an instruction count. We would keep the instruction count in the "record_end" structure, so that we could find it again later.

This is an optimization. There is a patch awaiting review that would add this feature. Basically the idea is that there are some functions that don't need to be traced because we will never want to debug them. Omitting these functions from the trace can make the trace smaller, therefore making replay faster and increasing the size of the programs that we can record.

There are currently some tests for reverse debugging in general, but none for process record / replay in specific. We need to create tests for several user-visible commands that are unique to process record (such as set record insn-max-num, set record limit). Also for manipulating the size of the buffer, and for "ring buffer" behavior.

For instance, we should have a tutorial of some sort.

There is a patch awaiting review [checked in] that reorganizes the existing database (alloc and free).

Msnyder has checked in a patch that seems to improve memory utilization by maybe 25 percent.

Currently we support x86, amd64, and moxie. Teawater is working on a MIPS port. We need more ports. Eg. ARM would be nice.

Currently we only support Linux. Other open source OSes would be nice.

Currently some instructions are only marginally supported, if at all. Support for recording segment registers is sketchy. We don't yet support floating point instructions or registers -- there is a patch awaiting check-in that supports the basic i387 architecture, but not yet for the other more advanced co-processors.

Currently we believe that we support signals that are delivered synchronously by the "kill" syscall, but we don't really know whether our support works for "real" signals (eg. an instruction that causes a segmentation violation) or for asynchronous signals.

There should be a way to ask for runtime statistics such as:

  1. What's my current position in the recording(done)
  2. How much memory is used by the recording
  3. (???)

None: ProcessRecord/WishList (last edited 2009-11-27 21:20:25 by AS-40816)

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