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

[Alex Bennée]

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
>> [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?

Yes. I assume the -drive doesn't actually have to be visible to the
guest, it's just the mechanism rr needs for saving snapshots?

> Are you using the latest version?
> If the both answers are 'yes', then can you share the kernel? My i386
> runs work normally.

I'll have a go with x86 first as aarch64 hasn't been proven yet.

>
>> 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


--
Alex Bennée