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

["Alex Bennée" <alex.bennee@linaro.org>]

Pavel Dovgalyuk <dovgaluk@ispras.ru> writes:

>> From: Alex Bennée [mailto:alex.bennee@linaro.org]
>> Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru> 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())

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.

--
Alex Bennée