From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18984 invoked by alias); 20 Oct 2008 23:36:51 -0000 Received: (qmail 18976 invoked by uid 22791); 20 Oct 2008 23:36:50 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.189) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Oct 2008 23:36:15 +0000 Received: by ti-out-0910.google.com with SMTP id d10so1036094tib.12 for ; Mon, 20 Oct 2008 16:36:12 -0700 (PDT) Received: by 10.110.20.15 with SMTP id 15mr5402992tit.28.1224545772465; Mon, 20 Oct 2008 16:36:12 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Mon, 20 Oct 2008 16:36:12 -0700 (PDT) Message-ID: Date: Mon, 20 Oct 2008 23:36:00 -0000 From: teawater To: "Michael Snyder" Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode? Cc: "Pedro Alves" , "gdb-patches@sourceware.org" In-Reply-To: <48FCC413.3040506@vmware.com> 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> <200810200109.55661.pedro@codesourcery.com> <48FBD342.5070905@vmware.com> <200810201844.30954.pedro@codesourcery.com> <48FCC413.3040506@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-10/txt/msg00497.txt.bz2 I think your mean is check breakpoint in address read_pc()+gdbarch_decr_pc_after_break (gdbarch) in record_wait, right? On Tue, Oct 21, 2008 at 01:46, Michael Snyder wrote: > Pedro Alves wrote: > >> I believe the correct thing for the target to do is to >> report `PC + decr_pc_after_breakpoint' on forward (replay or normal >> forward) >> breakpoint hits, if it is telling GDB that it succesfully >> inserted a software breakpoint. > > Yeah, you and Daniel have both said essentially the same. > And I think you're right. > > Hui, can you do this? > > Unfortunately, right now I think you are handling the > breakpoints in record.c (which is architecture-agnostic). > Maybe you'll have to check the decr_pc_after_break value. > >