From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23622 invoked by alias); 21 Oct 2008 06:52:38 -0000 Received: (qmail 23608 invoked by uid 22791); 21 Oct 2008 06:52:37 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.188) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Oct 2008 06:52:02 +0000 Received: by ti-out-0910.google.com with SMTP id d10so1141623tib.12 for ; Mon, 20 Oct 2008 23:51:59 -0700 (PDT) Received: by 10.110.33.15 with SMTP id g15mr5632022tig.35.1224571919841; Mon, 20 Oct 2008 23:51:59 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Mon, 20 Oct 2008 23:51:59 -0700 (PDT) Message-ID: Date: Tue, 21 Oct 2008 06:52:00 -0000 From: teawater To: "Pedro Alves" Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode? Cc: "Michael Snyder" , "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: <200810180210.16346.pedro@codesourcery.com> <48FCC413.3040506@vmware.com> <200810210121.07914.pedro@codesourcery.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-10/txt/msg00505.txt.bz2 2008-10-21 Hui Zhu * record.c (record_wait): Check breakpint before forward execute in replay mode. Check breakpoint use function "breakpoint_inserted_here_p" in replay mode. Set pc if forward execute and gdbarch_decr_pc_after_break is not 0 in replay mode. On Tue, Oct 21, 2008 at 14:51, teawater wrote: > Sorry for understand your mean so later Pedro. I made a new patch that > Set pc if forward execute and gdbarch_decr_pc_after_break is not 0 in > replay mode. How do you think about it? > > > And I think 20080930 branch is need your "adjust_pc_reverse.diff". Do > you mind I check it in? > > On Tue, Oct 21, 2008 at 08:21, Pedro Alves wrote: >> On Tuesday 21 October 2008 00:36:12, teawater wrote: >>> I think your mean is check breakpoint in address >>> read_pc()+gdbarch_decr_pc_after_break (gdbarch) in record_wait, right? >> >> Taking x86 as an example, when you're doing normal debugging and you >> hit a breakpoint (SIGTRAP), the first read_pc GDB does to check where >> what breakpoint was hit, will read back `breakpoint_PC + 1' --- GDB takes care >> getting rid of that `+ 1' offset in infrun.c:adjust_pc_after_break. The >> idea is for you to do the same as the kernel/hardware would --- still >> check for breakpoints at read_pc, but increment PC by 1 before reporting the >> breakpoint to GDB's core. E.g., see the `pc += gdbarch...' line from >> the patch I posted previously, something like: >> >> record.c:record_wait () >> { >> ... >> + /* Check for breakpoint hits in forward execution. */ >> + pc = read_pc (); >> + if (execution_direction == EXEC_FORWARD >> + && regular_breakpoint_inserted_here_p (pc) >> + /* && !single-stepping */) >> + { >> + status->kind = TARGET_WAITKIND_STOPPED; >> + status->value.sig = TARGET_SIGNAL_TRAP; >> + if (software_breakpoint_inserted_here_p (pc)) >> + { >> + pc += gdbarch_decr_pc_after_break (gdbarch); >> + write_pc (pc); >> + } >> + >> >> -- >> Pedro Alves >> >