From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 444 invoked by alias); 5 Aug 2002 18:49:48 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 431 invoked from network); 5 Aug 2002 18:49:45 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (209.53.16.3) by sources.redhat.com with SMTP; 5 Aug 2002 18:49:45 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 1131CD2CBD; Mon, 5 Aug 2002 11:49:21 -0700 (PDT) Date: Mon, 05 Aug 2002 11:49:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] enable software single step on alpha-osf Message-ID: <20020805184920.GC892@gnat.com> References: <20020718203205.GB26990@gnat.com> <3D4DBBC8.5000906@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D4DBBC8.5000906@ges.redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-08/txt/msg00100.txt.bz2 > Can you confirm that the code is encountering a situtation where both > breakpoints_inserted and singlestep_breakpoints_inserted_p are true. I > think this occures when doing a single step after stepping off of a > breakpoint. When single stepping off a breakpoint, only > singlestep_breakpoints_inserted_p would be true. > > If this is the case then the comments should make mention of it. It > also makes the re-ordered if statement part of the patch correct. Yes, I can confirm this, and this should happen fairly often: suppose you have inserted a regular breakpoint in your program, anywhere, and then do a single step. Before resuming the inferior, GDB will re-insert the breakpoints, and set breakpoints_inserted. At the same time, because we are doing a s/w single step, singlestep_breakpoints_inserted_p will be set too. Did I miss something? As for the re-ordering, I made it because I saw some regressions in the testsuite after switching to s/w single step. Unfortunately, I don't remember which ones, I would have to rerun the testsuite without this change to find them again. But the following comment explains in which cases the re-ordering was necessary: /* Check if a regular breakpoint has been hit before checking for a potential single step breakpoint. Otherwise, GDB will not see this breakpoint hit when stepping onto breakpoints. */ > The second part of the change is more tricky: > + stop_pc -= DECR_PC_AFTER_BREAK; > Is it fixing any failures? Software singlestep can be handled in two > different ways: > - as a breakpoint > - as a hardware single step > and which is prefered decides if/when there should be a decrement. Yes, this one is actually fixing most of the failures. I made several attempts at fixing the regressions before coming with this solution. This part of the code is quite tricky, and it seems to me that treating single-step breakpoints as hardware single step is the simplest way to handle them. I like this because the differences in processing between software and hardware single-step become smaller. See for instance the change in breakpoint.c which made the use of this macro disappear from this file. > Anyway, the thing I'm having trouble convincing myself that there can't > be a double decrement -- eg for a hardware watchpoint or similar. I've tried as much as I can to make sure this can not happen, but I am not familiar enough to have a good level of confidence in my analysis. All I can say is: this patch fixes all the regressions observed in the testsuite after switching to software single step. I know this is no absolute proof, but that gives me a certain level of confidence. -- Joel