On 05.10.2020 15:27, Paolo Bonzini wrote:
On 03/10/20 19:12, Pavel Dovgalyuk wrote:
GDB remote protocol supports reverse debugging of the targets.
It includes 'reverse step' and 'reverse continue' operations.
The first one finds the previous step of the execution,
and the second one is intended to stop at the last breakpoint that
would happen when the program is executed normally.
Reverse debugging is possible in the replay mode, when at least
one snapshot was created at the record or replay phase.
QEMU can use these snapshots for travelling back in time with GDB.
Running the execution in replay mode allows using GDB reverse debugging
commands:
- reverse-stepi (or rsi): Steps one instruction to the past.
QEMU loads on of the prior snapshots and proceeds to the desired
instruction forward. When that step is reaches, execution stops.
- reverse-continue (or rc): Runs execution "backwards".
QEMU tries to find breakpoint or watchpoint by loaded prior snapshot
and replaying the execution. Then QEMU loads snapshots again and
replays to the latest breakpoint. When there are no breakpoints in
the examined section of the execution, QEMU finds one more snapshot
and tries again. After the first snapshot is processed, execution
stops at this snapshot.
The set of patches include the following modifications:
- gdbstub update for reverse debugging support
- functions that automatically perform reverse step and reverse
continue operations
- hmp/qmp commands for manipulating the replay process
- improvement of the snapshotting for saving the execution step
in the snapshot parameters
- avocado-based acceptance tests for reverse debugging
The patches are available in the repository:
https://github.com/ispras/qemu/tree/rr-200901
v7 changes:
- updated snapshot info output format
- fixed qcow2 snapshot-related tests
Sorry, I'm still seeing a failure
timeout 15 /home/travis/build/bonzini/qemu/build/qemu-system-aarch64 -monitor
none -display none -chardev file,path=memory-replay.out,id=output -icount
shift=5,rr=replay,rrfile=record.bin -M virt -cpu max -display none
-semihosting-config enable=on,target=native,chardev=output -kernel memory
qemu-system-aarch64: terminating on signal 15 from pid 38312 (timeout)
That's very strange.
None of the patches affect RR for AArch64. Is this the real failure or
just a coincidence?
I also tried running this test on my local machine and got normal
execution time for replay:
real 0m0,968s
user 0m0,657s
sys 0m0,625s
By the way, this is an early RR test. Now we have more complex (and
easier to reproduce) avocado-based RR tests (for aarch64 too).
I.e. record and replay in this test are divided into two "tests",
and can cause races if running in parallel for some reason.
Shouldn't we just drop this one?
https://travis-ci.com/gitlab/bonzini/qemu/jobs/395029273
Paolo
