From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13207 invoked by alias); 2 Sep 2010 09:44:20 -0000 Received: (qmail 13197 invoked by uid 22791); 2 Sep 2010 09:44:19 -0000 X-SWARE-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from n10.bullet.mail.ac4.yahoo.com (HELO n10.bullet.mail.ac4.yahoo.com) (76.13.13.238) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Thu, 02 Sep 2010 09:44:14 +0000 Received: from [76.13.13.25] by n10.bullet.mail.ac4.yahoo.com with NNFMP; 02 Sep 2010 09:44:12 -0000 Received: from [67.195.9.83] by t4.bullet.mail.ac4.yahoo.com with NNFMP; 02 Sep 2010 09:44:12 -0000 Received: from [98.137.27.214] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 02 Sep 2010 09:44:12 -0000 Received: from [127.0.0.1] by omp124.mail.gq1.yahoo.com with NNFMP; 02 Sep 2010 09:44:12 -0000 Received: (qmail 47645 invoked by uid 60001); 2 Sep 2010 09:44:12 -0000 Message-ID: <290584.46112.qm@web112507.mail.gq1.yahoo.com> Received: from [123.238.26.59] by web112507.mail.gq1.yahoo.com via HTTP; Thu, 02 Sep 2010 02:44:12 PDT References: <4C712882.9040700@fano.co.uk> <312153.55254.qm@web112503.mail.gq1.yahoo.com> <4C7566D3.70109@fano.co.uk> Date: Thu, 02 Sep 2010 09:44:00 -0000 From: paawan oza Subject: Re: reverse debugging implementation To: "Engblom, Jakob" , gdb@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00002.txt.bz2 Hi, I am not sure whether that implementation will improve performance drastically compare to existing gdb reversible debuggin implementation. as does it involve -> stopping at every insn and find out whether insn is changing register or memory, and if register then record it (probably not every insn but depends on interval and no of memory changing insns) -> when you want to go back, you go back n-1 and forward execution till current-1, that probably involves single steeping which has performance impact. of course the record for memory is saved as we do not need to save architectural state at every insn, but performance !! Regards, Oza. ----- Original Message ---- From: "Engblom, Jakob" To: gdb@sourceware.org Sent: Thu, September 2, 2010 12:18:02 PM Subject: RE: reverse debugging implementation > > of memory locations before they are changed. Going back one > instruction then > > involves rolling back the memory changes, the registers are set up > then go > > forward n-1 instruction to go back one. If you go back in the gdb mailinglist, you will see that this is exactly how Wind River Simics does its reverse execution. Back up to a recent checkpoint, and then reexecute forward to some point in time. Silently record any breakpoints, and if you are running breakpoints backwards, go back to the checkpoint again and reexecute forward to the point in time where the breakpoint hits. Works very well for a full-system simulator where the entire target state is encapsulated and controlled. I believe similar things have been done in the RTL simulation field in the 1990s, but I have only anecdotal evidence. If you have checkpoints/snapshots and a deterministic simulator it is an "obvious" thing to do. /jakob Jakob Engblom | Wind River | Technical Marketing Manager - Simics Stockholm, Sweden mobile +46 734 368 958 | email jakob.engblom@windriver.com