Alex Bennée <alex.ben...@linaro.org> writes:
> Pavel Dovgalyuk <pavel.dovgal...@ispras.ru> writes: > >> On 07.09.2020 19:25, Alex Bennée wrote: >>> >>> Pavel Dovgalyuk <pavel.dovgal...@ispras.ru> writes: >>> >>>> On 07.09.2020 17:59, Alex Bennée wrote: >>>>> >>>>> Pavel Dovgalyuk <pavel.dovgal...@ispras.ru> writes: >>>>> >>>>>> On 07.09.2020 15:58, Alex Bennée wrote: >>>>>>> >>>>>>> Pavel Dovgalyuk <pavel.dovgal...@ispras.ru> writes: >>>>>>> >>>>>>>> From: Pavel Dovgalyuk <pavel.dovga...@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
