A Wish List for Fixes and Features for Process Record
In no particular order...
- Save and Restore execution logs (Status: IN!)
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.
- Make hardware watchpoints work (Status: IN!)
Software watchpoints already work with process record, but if you set a hardware watchpoint, gdb silently accepts it but will not stop for it.
- checkpoints / bookmarks / goto (Status: IN!)
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.
- skip functions (status: waiting for review)
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.
- Improve test coverage
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.
- Improve documentation
For instance, we should have a tutorial of some sort.
- Increase coverage of emulated sys calls
- Improve performance (speed and memory usage)
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.
- Improve coverage of cpu architectures
Currently we support x86, amd64, and moxie. Teawater is working on a MIPS port. We need more ports. Eg. ARM would be nice.
- Improve coverage of OS/ABIs
Currently we only support Linux. Other open source OSes would be nice.
- Support multi-threaded programs (Status: in review)
- Improve support for Intel x86 / x86_64 and AMD64 architectures
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.
- Improve support for signals / interrupts / exceptions
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.
- Runtime Statistics
There should be a way to ask for runtime statistics such as:
- What's my current position in the recording(done)
- How much memory is used by the recording
- (???)