From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uhfdl-0003Pi-Va for qemu-devel@nongnu.org; Wed, 29 May 2013 08:38:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uhfdc-0006OM-Qi for qemu-devel@nongnu.org; Wed, 29 May 2013 08:38:05 -0400 Received: from mail.ispras.ru ([83.149.199.45]:51201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uhfdc-0006Nz-JC for qemu-devel@nongnu.org; Wed, 29 May 2013 08:37:56 -0400 From: "Pavel Dovgaluk" References: <519667A7.9010902@greensocs.com> <1368938253.2611.4@driftwood> <019C9E6F-6C2C-4D59-BB88-974F498337EB@greensocs.com> In-Reply-To: <019C9E6F-6C2C-4D59-BB88-974F498337EB@greensocs.com> Date: Wed, 29 May 2013 16:37:53 +0400 Message-ID: <005a01ce5c69$571330c0$05399240$@Dovgaluk@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Content-Language: ru Subject: Re: [Qemu-devel] [RFC] reverse execution. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Mark Burton' , 'Peter Maydell' Cc: 'Blue Swirl' , 'qemu-devel' , =?ISO-8859-1?Q?'KONRAD_Fr=E9d=E9ric'?= Hello. > Spot on Peter, > The (simplistic) plan is simply to take a snapshot at regular intervals, when you want to step > backwards, you return to a snapshot, and then re-run forwards to 'just before you started'. > > To answer Blauwirbel, we can't "approximate" this - or 'binary search' for the right place - > we absolutely have to know exactly how to stop exactly 'just before'. To do that we need a > measure of where we are. Time isn't really what we want (It has a nasty habit of moving > forwards even when we are pretending to reverse it!). Ideally we need an instruction count. (I > say ideally, we could actually get away with something like a block count, but if blocks are > linked together etc, we would have to be careful). > > I still favor a dedicated counter for this, it seems to make more sense. But - I am wondering > about a 'basic block counter' rather than an 'instruction counter'. > Note - what I understand by a basic block is something that ends in a jump/branch of > some description. Hence, one thing I think you can say about a basic block is that each PC > value within it is unique. Hence, if I know the number of basic blocks executed, and the > current PC, then I should be able to re-run to there (assuming a deterministic system of > course). > > I'd be interested to know (a) if there is a sensible place for adding a basic block counter, > and (b) if people like this route better or worse than an instruction counter? We have implemented reverse debugging (through GDB) in QEMU. Translation of the instructions was changed to increment a special instruction counter before execution of every instruction. This counter is used to synchronize events that happen asynchronously in regular execution mode (timers, disk operations, etc). Checkpointing is also used in our implementation to rollback to previous state and then execute forward. Trying to count basic blocks is much more complicated task, because they may be interrupted with exceptions caused by MMU. Blocks' bounds are not deterministic because they depend on additional code that you translate, instruction where you stopped (using single-step or reverse-single-step commands). You can find some details here: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6178942&contentType=Conferenc e+Publications Pavel Dovgaluk