On 18/05/2013 20:52, Blue Swirl wrote:
On Fri, May 17, 2013 at 5:23 PM, KONRAD Frédéric
<fred.kon...@greensocs.com> wrote:
On 09/05/2013 19:54, Blue Swirl wrote:
On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric
<fred.kon...@greensocs.com> 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
Thanks for your help :).
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.
Well, finally we plan to do approximately this way:
We added a translation block counter, which is incremented by TCG code
the same way as icount, and raise a debug exception when we are at the
right location.
Unfortunately this is not sufficient in term of precision, we can jump
back 1 TB.
We have two choices:
a/ keep this "executed translation block" counter and "step by
step" go to the right location.
b/ transform this counter in a "executed instruction" counter like
icount and do
"step by step" execution when we are replaying.
The first is a bit difficult, as we don't have the exact PC location
where to stop, and the second can
be really slow (I don't have performance measure at the moment).
Maybe we can try mixing both: replaying to the start of the right TB,
then step by step going to the
right PC.
Fred
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
