From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32322 invoked by alias); 30 Oct 2008 11:06:59 -0000 Received: (qmail 32313 invoked by uid 22791); 30 Oct 2008 11:06:58 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 30 Oct 2008 11:06:55 +0000 Received: (qmail 27144 invoked from network); 30 Oct 2008 11:06:53 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Oct 2008 11:06:53 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode? Date: Thu, 30 Oct 2008 12:21:00 -0000 User-Agent: KMail/1.9.9 Cc: Michael Snyder , teawater References: <200810180210.16346.pedro@codesourcery.com> <49079788.6000702@vmware.com> In-Reply-To: <49079788.6000702@vmware.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <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/msg00702.txt.bz2 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 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. -- Pedro Alves