Re: [PATCH v3 09/15] replay: implement replay-seek command

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

Alex Bennée <alex.bennee@linaro.org> writes:

> Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:
>
>> On 07.09.2020 19:25, Alex Bennée wrote:
>>> 
>>> Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:
>>> 
>>>> On 07.09.2020 17:59, Alex Bennée wrote:
>>>>>
>>>>> Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:
>>>>>
>>>>>> On 07.09.2020 15:58, Alex Bennée wrote:
>>>>>>>
>>>>>>> Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:
>>>>>>>
>>>>>>>> From: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
>>>>>>>>
>>>>>>>> This patch adds hmp/qmp commands replay_seek/replay-seek that proceed
>>>>>>>> the execution to the specified instruction count.
>>>>>>>> The command automatically loads nearest snapshot and replays the execution
>>>>>>>> to find the desired instruction count.
>>>>>>>
>>>>>>> Should there be an initial snapshot created at instruction 0? Using a
>>>>>>> separate monitor channel:
>>>>>>
>>>>>> Right, you can't go to the prior state, when there is no preceding
>>>>>> snapshot available.
>>>>>
>>>>> It seems creating an initial snapshot automatically would be more user
>>>>
>>>> Please take a look at 'Snapshotting' section of docs/replay.txt.
>>>> Reverse debugging is considered to be run with disk image (overlay)
>>>> and rrsnapshot option of icount, which allows creating an initial
>>>> VM snapshot.
>>> 
>>> Given that I'm using the block device purely for VM snapshots I think it
>>> would be useful to document the minimal "no disk" approach - i.e. where
>>> the disk is only used for record/replay.
>>> 
>>> However I'm still having trouble. I can record the trace with:
>>> 
>>>    ./qemu-system-aarch64 -cpu cortex-a53 -display none -serial stdio \
>>>      -machine virt -kernel zephyr.elf -net none \
>>>      -icount shift=6,align=off,sleep=off,rr=record,rrfile=record.out,rrsnapshot=rrstart  \
>>>      -drive file=record.qcow2,if=none,id=rr \
>>>      -monitor telnet:127.0.0.1:4444 -S
>>
>> Can you provide your zephyr.elf image?
>>
>>> 
>>> which shows:
>>> 
>>>    (qemu) info snapshots
>>>    info snapshots
>>>    List of snapshots present on all disks:
>>>    ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
>>>    --        rrstart           653 KiB 2020-09-07 17:12:42 00:00:00.000          0
>>> 
>>> but do I need a whole separate overlay in the replay case? I thought
>>> supplying snapshot to the drive would prevent the replay case
>>> overwriting what has been recorded but with:
>>> 
>>>      -icount shift=6,align=off,sleep=off,rr=replay,rrfile=record.out \
>>>      -drive file=record.qcow2,if=none,id=rr,snapshot
>>
>> When you provide qcow2 (overlay or not) for snapshotting, you don't need 
>> any 'snapshot' option on drive.
>>
>>> 
>>> but I get:
>>> 
>>>    (qemu) info snapshots
>>>    info snapshots
>>>    There is no snapshot available.
>>> 
>>> so if I drop the ,snapshot from the line I can at least see the snapshot
>>> but continue doesn't seem to work:
>>> 
>>>    (qemu) info snapshots
>>>    info snapshots
>>>    List of snapshots present on all disks:
>>>    ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
>>>    --        rrstart           653 KiB 2020-09-07 17:12:42 00:00:00.000          0
>>>    (qemu) replay_break 190505
>>>    replay_break 190505
>>>    (qemu) c
>>>    c
>>>    (qemu) info replay
>>>    info replay
>>>    Replaying execution 'record.out': instruction count = 0
>>
>> It seems, that replay hangs. Can you try removing '-S' in record command 
>> line?
>
> That doesn't make any difference removing from both the record and
> replay cases. It seems to need a loadvm to start things off.
>
> I've sent you an image off list. Please let me know if you can
> replicate.

OK I can successfully use gdb to reverse debug the acceptance test (\o/)
so I suspect there are differences in the calling setup.

The first one is ensuring that rrsnapshot is set for both record and
replay. For this reason I think a more user friendly automatic snapshot
would be worth setting up when record/replay is being used.

-icount sleep=off definitely breaks things. Do we keep track of the
 icount bias as save and restore state?

-- 
Alex Bennée