From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9901 invoked by alias); 21 May 2005 14:39:54 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9885 invoked from network); 21 May 2005 14:39:47 -0000 Received: from unknown (HELO mail.netspace.net.au) (203.10.110.72) by sourceware.org with SMTP; 21 May 2005 14:39:47 -0000 Received: from [192.168.1.11] (220-253-29-14.VIC.netspace.net.au [220.253.29.14]) by mail.netspace.net.au (Postfix) with ESMTP id 4014671ED1 for ; Sun, 22 May 2005 00:39:45 +1000 (EST) Message-ID: <428F48A8.5090700@netspace.net.au> Date: Sat, 21 May 2005 14:39:00 -0000 From: Russell Shaw User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 MIME-Version: 1.0 Cc: gdb@sources.redhat.com Subject: Re: [discuss] Support for reverse-execution References: <20050516174649.GM19642@erizo.shearer.org> <20050520181515.GC2499@nevyn.them.org> <01c55ded$Blat.v2.4$11e9e260@zahav.net.il> <428F0DB8.40804@netspace.net.au> <01c55e01$Blat.v2.4$9e3e7a00@zahav.net.il> In-Reply-To: <01c55e01$Blat.v2.4$9e3e7a00@zahav.net.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00266.txt.bz2 Eli Zaretskii wrote: >>Date: Sat, 21 May 2005 20:30:16 +1000 >>From: Russell Shaw >>Cc: gdb@sources.redhat.com >> >>It'd be better to store the state of every step in to a circular buffer >>of size 1000 (the user could change that size with a command). > > When you say ``it'd be better'', what is the alternative that you > think is worse than your suggestion? What I wrote didn't say how many > previous states to remember, nor what data structure to use for that. > > Also, I hope you don't mean ``every step'', but rather ``every stop''. > What I suggested didn't involve single-stepping the program, so GDB > can only collect the target state when the target stops, not after > each instruction. Yes, that's what i meant (every step). It could be configureable so that the policy can be set to every user-stop, every function call, or disabled alltogether. The idea is that you could run from main() until a segfault happens, then "back 10" and step thru the last few actions. >>That way, there's only one backwards command to remember, and maybe a >>command to change the history buffer size. > > That's essentially what I suggested: to have a single command to go > back to one of the places where we have enough information to restore > the target state. I was hoping to have target state for all of the last 100 or 1000 steps. There could be two things the user chooses: When you go back to a previous point then start stepping, all you see is a replay of what happened, rather than any real interactive or live executions happening. When you step past the current context, then 'real' simulation is again happening as usual, or When you go back to a previous point then start stepping, then 'real' simulation is again happening as usual.