From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29356 invoked by alias); 31 Oct 2008 00:03:55 -0000 Received: (qmail 29173 invoked by uid 22791); 31 Oct 2008 00:03:54 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.186) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 31 Oct 2008 00:01:54 +0000 Received: by ti-out-0910.google.com with SMTP id d10so419312tib.12 for ; Thu, 30 Oct 2008 17:01:46 -0700 (PDT) Received: by 10.110.37.17 with SMTP id k17mr3573329tik.26.1225372906451; Thu, 30 Oct 2008 06:21:46 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Thu, 30 Oct 2008 06:21:46 -0700 (PDT) Message-ID: Date: Fri, 31 Oct 2008 00:25:00 -0000 From: teawater To: "Pedro Alves" Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode? Cc: gdb-patches@sourceware.org, "Michael Snyder" In-Reply-To: <200810301107.23536.pedro@codesourcery.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> <49079788.6000702@vmware.com> <200810301107.23536.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/msg00716.txt.bz2 Hi Pedro, On Thu, Oct 30, 2008 at 19:07, Pedro Alves wrote: > > On Tuesday 28 October 2008 22:51:52, Michael Snyder wrote: > > > Well, before I can evaluate the patch, I need a test case > > to see what behavior it is fixing. Doesn't have to be a > > formal DEJAGNU script, just something like the printf example > > that you posted for the other bug. > > > > Right now, I am unable to get the reverse-20080930-branch > > to exhibit any bad behavior that I could attribute to this > > issue. It seems to work just fine... > > Wouldn't that be the extended nop+goto example I posted? > > http://sourceware.org/ml/gdb-patches/2008-10/msg00599.html Yes, It's OK with the newest patch. > > Hui, I'm now lost in this huge thread that never seems to > end, but I think that the last patch I saw, you still > missed that you should check for software_breakpoint_inserted_here_p > before doing the adjustment (see adjust_pc_after_break) --- it was > there in the first patch I posted to address this issue. > > This decr after break business sucks. For remote targets implementing > software breakpoints, it would probably be best if we had a remote protocol > feature with a corresponding property for this at the target_ops level that > overrides the gdbarch setting. There are probably many targets out there > implementing Z0 breakpoints that do the adjustment themselves. It's just > that it's not common to trip on it, so it gets by. That is a really good idea. Maybe we can add a special interface in target_ops tell the infrun.c that this PC need adjust_pc_after_break or not. Thanks, Hui