From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9476 invoked by alias); 18 Jan 2004 07:05:56 -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 9364 invoked from network); 18 Jan 2004 07:05:54 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 18 Jan 2004 07:05:54 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.24) id 1Ai707-0008L1-Da; Sun, 18 Jan 2004 02:05:39 -0500 Date: Sun, 18 Jan 2004 07:05:00 -0000 Message-Id: From: Eli Zaretskii To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com In-reply-to: <20040117222007.GA23563@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 17 Jan 2004 17:20:07 -0500) Subject: Re: RFC: Centralize DECR_PC_AFTER_BREAK handling from infrun Reply-to: Eli Zaretskii References: <20040117222007.GA23563@nevyn.them.org> X-SW-Source: 2004-01/txt/msg00467.txt.bz2 > Date: Sat, 17 Jan 2004 17:20:07 -0500 > From: Daniel Jacobowitz > > One case, HANDLE_NONSTEPPABLE_WATCHPOINTS and DECR_PC_AFTER_BREAK, is simply > removed. There are no targets using this combination, and if one is added, > it's non-obvious whether a nonsteppable watchpoint really should be affected > by DECR_PC_AFTER_BREAK. Right, but since we don't really know what that feature was about, I'd suggest to leave a comment in adjust_pc_after_break that mentions HANDLE_NONSTEPPABLE_WATCHPOINTS and that its support, if needed, should be added. > * breakpoint.c (software_breakpoint_inserted_here_p): New function. > (bpstat_stop_status): Don't decrement PC. > * breakpoint.h (software_breakpoint_inserted_here_p): Add > prototype. > * infrun.c (adjust_pc_after_break): New function. > (handle_inferior_event): Call it, early. Remove later references > to DECR_PC_AFTER_BREAK. > (normal_stop): Add commentary. What happens if a location has both software and hardware breakpoints? Does the code still DTRT? > + /* If we've hit a breakpoint, we'll be stopped with SIGTRAP. */ > + if (ecs->ws.kind != TARGET_WAITKIND_STOPPED) > + return; > + > + if (ecs->ws.value.sig != TARGET_SIGNAL_TRAP) > + return; The original code didn't check these conditions, right? So why add them here? (Also, the comment doesn't seem to describe the two tests, only the second one.)