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 > > 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 >>> >
