Re: [Qemu-devel] [PATCH v4 00/19] reverse debugging

[Pavel Dovgalyuk]

> From: Alex Bennée [mailto:address@hidden
> Pavel Dovgalyuk <address@hidden> writes:
> 
> >> From: Alex Bennée [mailto:address@hidden
> >> Pavel Dovgalyuk <address@hidden> writes:
> >>
> >> >> From: Alex Bennée [mailto:address@hidden
> >> >> Pavel Dovgalyuk <address@hidden> writes:
> >> >>
> >> >> > Ping?
> >> >>
> >> >> I started having a look but I ran into this straight away. First I
> >> >> recorded a boot of the kernel:
> >> >>
> >> >>   ./aarch64-softmmu/qemu-system-aarch64 -machine virt,graphics=on,gic-
> >> >> version=3,virtualization=on -cpu cortex-a53 --serial mon:stdio -display 
> >> >> none -kernel
> >> >> ../images/aarch64-current-linux-initrd-guest.img -icount
> >> shift=7,rr=record,rrfile=replay.bin
> >> >>
> >> >> Then played back:
> >> >>
> >> >>   ./aarch64-softmmu/qemu-system-aarch64 -machine virt,graphics=on,gic-
> >> >> version=3,virtualization=on -cpu cortex-a53 --serial mon:stdio -display 
> >> >> none -kernel
> >> >> ../images/aarch64-current-linux-initrd-guest.img -icount
> >> shift=7,rr=replay,rrfile=replay.bin -
> >> >> s -S
> >> >
> >> > This looks ok, but...
> >> >
> >> >> And did the following on gdb:
> >> >>
> >> >> (gdb) i
> >> >> 0x0000000040000004 in ?? ()
> >> >> => 0x40000004:  mov     x1, xzr
> >> >>    0x40000008:  mov     x2, xzr
> >> >>    0x4000000c:  mov     x3, xzr
> >> >> (gdb)
> >> >> 0x0000000040000008 in ?? ()
> >> >> => 0x40000008:  mov     x2, xzr
> >> >>    0x4000000c:  mov     x3, xzr
> >> >>    0x40000010:  ldr     x4, 0x40000020
> >> >> (gdb)
> >> >> 0x000000004000000c in ?? ()
> >> >> => 0x4000000c:  mov     x3, xzr
> >> >>    0x40000010:  ldr     x4, 0x40000020
> >> >>    0x40000014:  br      x4
> >> >> (gdb)
> >> >> 0x0000000040000010 in ?? ()
> >> >> => 0x40000010:  ldr     x4, 0x40000020
> >> >>    0x40000014:  br      x4
> >> >>    0x40000018:  .inst   0x44000000 ; undefined
> >> >> (gdb)
> >> >> 0x0000000040000014 in ?? ()
> >> >> => 0x40000014:  br      x4
> >> >>    0x40000018:  .inst   0x44000000 ; undefined
> >> >>    0x4000001c:  .inst   0x00000000 ; undefined
> >> >> (gdb) p/x $x4
> >> >> $1 = 0x40080000
> >> >> (gdb) reverse-stepi
> >> >> warning: Remote failure reply: E14
> >> >>
> >> >> Surely this is the simple case and doesn't require any snapshots for
> >> >> block devices as there are none. Am I missing something?
> >> >
> >> > Reverse debugging requires the snapshotting. QEMU can't revert the VM 
> >> > state without the
> >> snapshots.
> >> > You can try adding an empty qcow2 image to allow snapshotting there.
> >>
> >> I suspect a recent patch has broken locking again:
> >>
> >> Starting program: 
> >> /home/alex/lsrc/qemu/qemu.git/aarch64-softmmu/qemu-system-aarch64 -
> machine
> >> virt,graphics=on,gic-version=3,virtualization=on -cpu cortex-a53 --serial 
> >> mon:stdio -
> display
> >> none -kernel ../images/aarch64-current-linux-initrd-guest.img -icount
> >> shift=7,rr=replay,rrfile=replay.bin,rrsnapshot=debug -drive
> >> file=rr.qcow2,if=none,snapshot,id=rr -s -S

Just noticed. If you are using VM snapshots, then you should disable "snapshot" 
option
of the drive. Like that: -drive file=rr.qcow2,if=none

BTW, similar command line for aarch64 worked for me.
I just removed "-display=none" for convenience.

Pavel Dovgalyuk