From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21047 invoked by alias); 25 Aug 2010 06:30:24 -0000 Received: (qmail 21037 invoked by uid 22791); 25 Aug 2010 06:30:22 -0000 X-SWARE-Spam-Status: No, hits=1.5 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 n1-vm1.bullet.mail.gq1.yahoo.com (HELO n1-vm1.bullet.mail.gq1.yahoo.com) (67.195.23.153) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 25 Aug 2010 06:30:16 +0000 Received: from [67.195.9.81] by n1.bullet.mail.gq1.yahoo.com with NNFMP; 25 Aug 2010 06:30:14 -0000 Received: from [98.137.27.214] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 25 Aug 2010 06:30:14 -0000 Received: from [127.0.0.1] by omp124.mail.gq1.yahoo.com with NNFMP; 25 Aug 2010 06:30:14 -0000 Received: (qmail 55996 invoked by uid 60001); 25 Aug 2010 06:30:14 -0000 Message-ID: <312153.55254.qm@web112503.mail.gq1.yahoo.com> Received: from [72.163.183.56] by web112503.mail.gq1.yahoo.com via HTTP; Tue, 24 Aug 2010 23:30:13 PDT References: <4C712882.9040700@fano.co.uk> Date: Wed, 25 Aug 2010 06:30:00 -0000 From: paawan oza Subject: Re: reverse debugging implementation To: David McQuillan , gdb@sourceware.org In-Reply-To: <4C712882.9040700@fano.co.uk> 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-08/txt/msg00146.txt.bz2 Hi, please find my inline. Regards, Oza. ----- Original Message ---- From: David McQuillan To: gdb@sourceware.org Sent: Sun, August 22, 2010 7:09:14 PM Subject: reverse debugging implementation Hi, I see gdb now supports reverse debugging. This is something I implemented for myself a number of years ago with my own simulators when I was working on testing some compilers and other stuff. That all died a long time ago but some of the ideas from it might be useful if you haven't done them already. Firstly as far as I can see gdb saves all the state change for every instruction. This is unnecessary, all you have to do is save the state of the cpu every few thousand instructions and for each instruction only save the state 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. oza : so does it mean that instructions which changes memory you can take one step backward, but instructions which have changed registers you can not step back by one instruction but n-1. so we lost the ability to track back by instruction, yes of course it is performance gain by the factor of n. I also had debug instructions to mark the current spot, then one could go between a few different different states easily to check on the difference. I think practically everything else I had about what to do about library calls is there - I intercepted system calls so they weren't redone just the old results returned so I had to save both before and after looks. Special work had to be done about allocating and freeing space and I only had serial files and no special device access so you can see I had a fairly straightforward environment. Oza: -> Is it possible to revoke all system calls, such as revoking sent signal etc, doesnt it ned kernel change in all cases and probably making ptrace more powerful. ? If you used virtual memory tricks it might be possible to save the state of the memory that way instead of even taking before looks. It would slow going backwards a bit but I never noticed any particular delay going back an instruction and machines have sped up and there's lots more memory nowadays. Oza -> does it involve saving whole virtuall address space on disk or something ? Cheers, David McQuillan