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:
> >>
> >> > 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
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffd8536700 (LWP 32452)]
> [New Thread 0x7fffd5bb3700 (LWP 32453)]
> [New Thread 0x7fffd4eab700 (LWP 32454)]
> **
> ERROR:replay/replay-time.c:49:replay_read_clock: assertion failed: 
> (replay_file &&
> replay_mutex_locked())

Have you recorded it with the attached disk before replaying?
Are you using the latest version?
If the both answers are 'yes', then can you share the kernel? My i386 runs work 
normally.

> Once I have the linux-user TCG tests merged I'm planning on focusing on
> the system emulation tests and we should be able to add some
> record/replay tests to defend the behaviour.

That will be great.
There are some Ciro's attempts on that: 
https://github.com/cirosantilli/qemu-test/blob/master/arm/rr

Pavel Dovgalyuk