From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31330 invoked by alias); 16 Sep 2008 15:14:38 -0000 Received: (qmail 31320 invoked by uid 22791); 16 Sep 2008 15:14:37 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.187) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 Sep 2008 15:14:02 +0000 Received: by ti-out-0910.google.com with SMTP id d10so1813729tib.12 for ; Tue, 16 Sep 2008 08:13:59 -0700 (PDT) Received: by 10.110.69.5 with SMTP id r5mr1560265tia.17.1221578039007; Tue, 16 Sep 2008 08:13:59 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Tue, 16 Sep 2008 08:13:58 -0700 (PDT) Message-ID: Date: Tue, 16 Sep 2008 15:14:00 -0000 From: teawater To: "Michael Snyder" , "Daniel Jacobowitz" Subject: Re: [reverse RFA] no singlestep-over-BP in reverse Cc: "gdb-patches@sourceware.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48CEAA05.8050006@vmware.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00350.txt.bz2 On Tue, Sep 16, 2008 at 23:03, teawater wrote: > Hi guys, > > I think we need to decide the behavior of reverse mode breakpoint. > > In forward mode, it's clear that CPU stop in address of breakpoint. > The instruction in this address will not be executed. > > In reverse mode, If CPU stop in address of breakpoint, I think we have > 2 choices: > > 1. The instruction in this address already reverse executed, it make > program status back to before forward execute this instruction. > Good for it is: > This way make reverse breakpoint same with simple BP. > If program break in reverse mode and got forward execute command. It > don't need special process. > Bad for it is: > This instruction already reverse executed, I think it's not the > original idea of breakpoint. I think the original idea of breakpoint > is stop the program before the instruction forward and reverse > execute. > And for record and replay type reverse target such as inside record > and gdb-freeplay(Sorry I am not very clear), to implement this BP are > not hard. But maybe not easy for others. > > 2. The instr in this address will not reverse executed, it make > program status in after forward execute this instruction. > Good for it is: > Maybe this is the original idea of breakpoint. > Bad for it is: > If program break in reverse mode and got forward execute command. It > need special process. > Maybe some reverse target can't support it. > > Maybe we need support both of them. Target choice what it want, maybe > both of them. And target need to decide if he want a single step to > jump a BP or not. If we want support both of them. Maybe we can support a command make user can get the type and set the type(Maybe some target just support 1 tyoe). > > How do you think about it? > > > Thanks, > Hui > > > > > On Tue, Sep 16, 2008 at 12:21, teawater wrote: >> I think maybe some reverse target (in the future?) need it. >> Someone already know it already deal the breakpoint. But the others >> will not know. Maybe I will change inside record to second type. >> >> >> If this single step affect some target, how about let target choice it >> with itself? >> >> Thanks, >> Hui >> >> >> >> >> On Tue, Sep 16, 2008 at 02:31, Michael Snyder wrote: >>> When we're stopped at a breakpoint and we want to >>> continue in reverse, we're not actually going to >>> execute the instruction at the breakpoint -- we're >>> going to de-execute the previous instruction. >>> >>> Therefore there's no need to singlestep before >>> inserting breakpoints. In fact it would be a bad >>> idea to do so, because if there is a breakpoint at >>> the previous instruction, we WANT to hit it. >>> >>> Note that this patch is to be applied to the reverse branch. >>> >>> 2008-09-15 Michael Snyder >>> >>> * infrun.c (proceed): No need to singlestep over a breakpoint >>> when resuming in reverse. >>> >>> Index: infrun.c >>> =================================================================== >>> RCS file: /cvs/src/src/gdb/infrun.c,v >>> retrieving revision 1.300.2.5 >>> diff -u -p -r1.300.2.5 infrun.c >>> --- infrun.c 5 Sep 2008 03:37:10 -0000 1.300.2.5 >>> +++ infrun.c 15 Sep 2008 18:28:29 -0000 >>> @@ -1226,11 +1226,17 @@ proceed (CORE_ADDR addr, enum target_sig >>> >>> if (addr == (CORE_ADDR) -1) >>> { >>> - if (pc == stop_pc && breakpoint_here_p (pc)) >>> + if (pc == stop_pc && breakpoint_here_p (pc) >>> + && target_get_execution_direction () == EXEC_FORWARD) >>> /* There is a breakpoint at the address we will resume at, >>> step one instruction before inserting breakpoints so that >>> we do not stop right away (and report a second hit at this >>> - breakpoint). */ >>> + breakpoint). >>> + >>> + Note, we don't do this in reverse, because we won't >>> + actually be executing the breakpoint insn anyway. >>> + We'll be (un-)executing the previous instruction. */ >>> + >>> oneproc = 1; >>> else if (gdbarch_single_step_through_delay_p (gdbarch) >>> && gdbarch_single_step_through_delay (gdbarch, >>> >>> >> >