From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1665 invoked by alias); 20 May 2005 10:37:41 -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 1587 invoked from network); 20 May 2005 10:37:29 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 20 May 2005 10:37:29 -0000 Received: from zaretski (IGLD-83-130-247-87.inter.net.il [83.130.247.87]) by romy.inter.net.il (MOS 3.5.8-GR) with ESMTP id BGY07505 (AUTH halo1); Fri, 20 May 2005 13:36:08 +0300 (IDT) Date: Fri, 20 May 2005 10:37:00 -0000 From: "Eli Zaretskii" To: Johan Rydberg Message-ID: <01c55d27$Blat.v2.4$69471120@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: dan@shearer.org, gdb@sources.redhat.com In-reply-to: <428C8E04.3000305@virtutech.com> (message from Johan Rydberg on Thu, 19 May 2005 15:00:52 +0200) Subject: Re: [discuss] Support for reverse-execution Reply-to: Eli Zaretskii References: <20050519012254.GZ19642@erizo.shearer.org> <428C8E04.3000305@virtutech.com> X-SW-Source: 2005-05/txt/msg00204.txt.bz2 > Date: Thu, 19 May 2005 15:00:52 +0200 > From: Johan Rydberg > Cc: gdb@sources.redhat.com > > Here's a patch against CVS that implements the following commands: > > - rstep, rstepi > - rnext, rnexti > > The obvious commands "rcontinue" and "rfinished" are not yet > implemented, and therefor not included in this patch. The command > names are of course up for discussion. I don't mind these names; reverse-next etc. seem awkward, but rnext etc. are okay, I think. However, see my other comments in response to Daniel. > What I have done is add a new variable, step_direction, that can either > be STEP_DIR_FORWARD or STEP_DIR_REVERSE. I'd prefer STEP_FORWARD and STEP_BACKWARD. > To implement "rnext" I had to add a new target-specific function that > tries to figure out the address of the call instruction based on the > last executed instruction and the instruction to be executed, IF the > current instruction can be identified as a return insn. Sorry, I'm confused. Isn't it right that if I'm stepping backwards through code such as this: i += 1; foo (i); =>i = 0; where "=>" shows the current source line, then typing `rnext' once will get me to this: i += 1; =>foo (i); i = 0; which means I'm now before the CALL insn that calls `foo'? If so, what ``return insn'' were you talking about? If it's the return instruction that returns from `foo', then that insn is inside the code generatedfor `foo', which GDB won't see. What am I missing? > + add_com ("rnext", class_run, rnext_command, > + "Step program until it reaches the previous source line.\n\ "Go backwards until the program reaches the source line before the current one." > + add_com_alias ("rn", "rnext", class_run, 1); Do we want another alias called "previous"? > +extern enum step_direction_kind step_direction; Yuk! a global variable! > + if (step_direction == STEP_DIR_FORWARD) > + target_resume (resume_ptid, step, sig); > + else > + { > + target_reverse (resume_ptid, step); > + } I'd prefer that target_resume accepted the direction argument. Is there something that I'm missing that makes this hard or impossible?