From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30845 invoked by alias); 25 Aug 2010 18:55:01 -0000 Received: (qmail 30829 invoked by uid 22791); 25 Aug 2010 18:54:59 -0000 X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mtaout03-winn.ispmail.ntl.com (HELO mtaout03-winn.ispmail.ntl.com) (81.103.221.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Aug 2010 18:54:50 +0000 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100825185416.TRRX3075.mtaout03-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Wed, 25 Aug 2010 19:54:16 +0100 Received: from [192.168.0.2] (really [86.9.212.44]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20100825185415.YERR13964.aamtaout03-winn.ispmail.ntl.com@[192.168.0.2]>; Wed, 25 Aug 2010 19:54:15 +0100 Message-ID: <4C7566D3.70109@fano.co.uk> Date: Wed, 25 Aug 2010 18:55:00 -0000 From: David McQuillan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: paawan oza CC: gdb@sourceware.org Subject: Re: reverse debugging implementation References: <4C712882.9040700@fano.co.uk> <312153.55254.qm@web112503.mail.gq1.yahoo.com> In-Reply-To: <312153.55254.qm@web112503.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00150.txt.bz2 Hi paawan, my replies about what I did.. David On 25/08/2010 07:30, paawan oza wrote: >... > 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. No, every single step backwards involved going back to the last time the registers were saved unrolling the memory changes on the way. The simulators kept the instruction count so I simply set them to stop when they executed the current instruction count - count when registers were saved - 1 instructions. The only special code in the simulators was to do the before looks of memory writes so it was quite a minimal change for existing simulators. >... > 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. ? No, I simply saved any the memory the system calls would change plus the registers after the call. Actually I didn't save the state afterwards, I used the same space for the before look and it swapped between being the before look and the after look depending on whether I had rolled to before the call. The system calls were not redone when going forward after having looked at a previous point. Thus for example if you rolled back over typewriter input on going forward it would return what was typed the last time. I didn't actually free memory at the time a free was done. That was delayed until I'd used up too much space on saving memory before looks and was then freed at the same time as that. The serial files bit was a special to allow changes to be made to the state after rewinding to a previous point and also one might want a monitor file to be written to again rather than just setting the memory when redoing instructions going forwards. If one only has serial files and a simple environment one can change the previous state, then before going forward one has to reset the file pointers and free any memory that was allocated at a future point. It could be done with something more complicated but that was my only need and I actually didn't need to do it much - being able to view what went wrong in detail going backwards and forwards is quite enough facility for most purposes when debugging without trying to roll back the system in general. > 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 > ? No I was just pointing out that one could set the writeable pages read only after saving the registers then just copy whole pages and set them writeable as required going forwards. It's not something I did but it would mean the simulators needn't even do memory before looks and if the time between register saves was made something like a few million instructions rather than the few thousand I did it would be quite economic on memory. It might help with dealing with memory frees properly as well rather than leaving the space visible like I did. Going back a few million instructions and forward again would be practically instantaneous as far as a user is concerned with modern processors. On performance with the way I did it I always ran with it so a backtrack could be done and had it set so it could go back a few million instructions before the earlier bits were thrown away. The saving of the memory was only a small overall overhead on speed. David