qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v7 00/14] Reverse debugging


From: Pavel Dovgalyuk
Subject: Re: [PATCH v7 00/14] Reverse debugging
Date: Mon, 5 Oct 2020 16:45:36 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]