[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] reverse execution.
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] [RFC] reverse execution. |
Date: |
Sat, 18 May 2013 18:52:24 +0000 |
On Fri, May 17, 2013 at 5:23 PM, KONRAD Frédéric
<address@hidden> wrote:
> On 09/05/2013 19:54, Blue Swirl wrote:
>>
>> On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric
>> <address@hidden> wrote:
>>>
>>> Hi,
>>>
>>> We are trying to find a way to do reverse execution happen with QEMU.
>>>
>>> Actually, it is possible to debug the guest through the gdbstub, we want
>>> to
>>> make the reverse execution possible with GDB as well.
>>>
>>> How we are trying to make that working (basically without optimisation):
>>>
>>> -QEMU takes regular snapshot of the VM:
>>> that can be done with the save vm code without optimisation first.
>>>
>>> -When the VM is stopped and GDB requests a reverse-step:
>>> load the last snapshot and replay to one instruction before the
>>> current
>>> PC.
>>>
>>> There are one issue with that for now (for a basic running reverse
>>> execution):
>>> -How to stop one instruction before the actual PC.
>>
>> Add a special translation mode for reverse execution where the next PC
>> is checked after each instruction. Alternatively, you could make
>> temporary snapshots during this mode (first 1s intervals, then 0.1s
>> etc) which could be used to find the location. I think this way was
>> discussed briefly earlier in the list, please check the archives.
>>
>
> Hi, thanks for your answer!
>
> I didn't find the discussion in the archive.. Do you have a clue? (Title or
> sender?)
Paul Brook (long time QEMU developer) made a paper about this together
with Daniel Jacobowitz:
http://www.linuxsymposium.org/archives/GCC/Reprints-2007/jacobowitz-reprint.pdf
IIRC Paul also mentioned some techniques on the list at that time but
I couldn't find that in the archives.
Other related discussions:
http://article.gmane.org/gmane.comp.emulators.qemu/88447
http://article.gmane.org/gmane.comp.emulators.qemu/94861
http://article.gmane.org/gmane.comp.emulators.qemu/154572
Also this site contains some overview of reverse debugging:
http://jakob.engbloms.se/archives/1554
>
> For now we tried some other things which are not working very well,
>
> It appeared that the replay is not deterministic even with icount:
> - the whole icount mechanism is not saved with save_vm (which can be
> achieved by moving qemu_icount to TimerState according to Paolo)
> - replaying two times the same thing and stopping at a specific
> breakpoint show two differents vmclock, so replaying the
> same amount of time don't work, and we abandoned this idea.
>
> We tried to count the amount of time tcg_qemu_tb_exec exited with having
> executed some TB and we stopped one before for the replay.
> This is nearly working but:
> - tcg_qemu_tb_exec exits a little more time during the first replay,
> seems the TB linked list is split dynamically?
> - this works with the next replay (reverse-stepi) but we can't stop at
> the exact PC instruction with this method.
>
> So we will try to add an instruction counter in the CPUState and increments
> it after each instruction in the translation code,
> which I think is approximately what you suggest.
> Then when replaying the code from the snapshot, we will check the amount of
> executed instruction and stop one instruction before.
> Maybe we can re-use icount mechanism but this might be a lot more
> complicated as it is a de-counter?
>
> Can this be working?
>
> Maybe we will need to trace the PC from the snapshot to the exact location?
That should be easy, but not the fastest way.
> Or use both mechanism to get the right location?
Yes, you could load VM from previous snapshot and then use icount or
just host timer to get approximately halfway. Make a new snapshot and
then try again, starting from that snapshot. When you get close
enough, singlestep to the final instruction.
>
> Thanks,
> Fred
>
>
>>> We though that using "-icount" and stop the guest a little time before
>>> the
>>> actual position would give us the right behavior (We use a qemu_timer
>>> with
>>> vm_clock to stop the vm at the good time), but it seems that it is not
>>> deterministic, and not reproducable.
>>>
>>> Is that normal?
>>>
>>> We don't make any input during the replay, and we though that it can be
>>> caused
>>> by some timer interruption but "-icount" is using a virtual timer as I
>>> understand?
>>>
>>> We have two other ideas:
>>>
>>> -Using TCI and count each instruction executed by the processor,
>>> then
>>> stop
>>> one instruction before the actual position. This seems slower.
>>>
>>> -Using single-step to count each instruction, then stop one
>>> instruction
>>> before the actual position.
>>>
>>> Would that be better?
>>>
>>> For now we can restore the VM from the last snapshot, when we do a
>>> reverse-step
>>> but we can't stop at the exact position.
>>>
>>> Thanks,
>>> Fred
>>>
>
- [Qemu-devel] [RFC] reverse execution., KONRAD Frédéric, 2013/05/07
- Re: [Qemu-devel] [RFC] reverse execution., Rob Landley, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Peter Maydell, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Mark Burton, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Peter Maydell, 2013/05/19
- Message not available
- Re: [Qemu-devel] [RFC] reverse execution., Brendan Dolan-Gavitt, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Mark Burton, 2013/05/20
- Re: [Qemu-devel] [RFC] reverse execution., Rob Landley, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Mark Burton, 2013/05/20
- Re: [Qemu-devel] [RFC] reverse execution., Pavel Dovgaluk, 2013/05/29