From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22473 invoked by alias); 16 Aug 2002 18:52:08 -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 22459 invoked from network); 16 Aug 2002 18:52:07 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 16 Aug 2002 18:52:07 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g7GIc9l29605 for ; Fri, 16 Aug 2002 14:38:09 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g7GIq3u02636; Fri, 16 Aug 2002 14:52:04 -0400 Received: from romulus.sfbay.redhat.com (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g7GIq2e23329; Fri, 16 Aug 2002 11:52:02 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g7GIpxF30849; Fri, 16 Aug 2002 11:51:59 -0700 Date: Fri, 16 Aug 2002 11:52:00 -0000 From: Kevin Buettner Message-Id: <1020816185159.ZM30848@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [patch/ob] not_a_breakpoint -> not_a_sw_breakpoint" (Aug 16, 1:34pm) References: <3D5D1C3E.8070203@ges.redhat.com> <1020816164312.ZM11179@localhost.localdomain> <3D5D37A7.2090003@ges.redhat.com> To: Andrew Cagney , Kevin Buettner Subject: Re: [patch/ob] not_a_breakpoint -> not_a_sw_breakpoint Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg00440.txt.bz2 On Aug 16, 1:34pm, Andrew Cagney wrote: > > On Aug 16, 11:37am, Andrew Cagney wrote: > > > > > >> This patch renames the ``not_a_breakpoint'' parameter of > >> bpstat_stop_status() to the more correct ``not_a_sw_breakpoint'' so that > >> it is clear that it is indicating nothing about hardware breakpoints. > > > > > > This may be a good change, but I don't think it's obvious. Could > > you at least explain the reasoning that lead you to conclude that > > the parameter in question indicates nothing about hardware breakpoints? > > The variable is used vis: > > bpstat_stop_status (CORE_ADDR *pc, int not_a_sw_breakpoint) > { > [...] > /* Get the address where the breakpoint would have been. The > "not_a_sw_breakpoint" argument is meant to distinguish between a > breakpoint trap event and a trace/singlestep trap event. For a > trace/singlestep trap event, we would not want to subtract > DECR_PC_AFTER_BREAK from the PC. */ > > bp_addr = *pc - (not_a_sw_breakpoint && !SOFTWARE_SINGLE_STEP_P () ? > 0 : DECR_PC_AFTER_BREAK); > > > Later in the code appears: > > if (DECR_PC_AFTER_HW_BREAK != 0) > { > *pc = *pc - DECR_PC_AFTER_HW_BREAK; > write_pc (*pc); > } > > if not_a_sw_breakpoint applied to hardware breakpoints then the above > decrement would be guarded by not_a_sw_breakpoint. > > BTW, an even more correct name is ``not_a_sw_breakpoint_trap''. > However, Joel might end up adding something better than that. Your reasoning is sound so long as we assume that the code that you're basing your reasoning on isn't bitrotted. (I only see one target with a non-zero DECR_PC_AFTER_HW_BREAK, and I'll bet that hasn't been tested in a while.) What I'd like to be convinced of is that the conditions which are used to instantiate ``not_a_sw_breakpoint'' really imply that that we could be stopped due to a hardware watchpoint, but not a software breakpoint trap. The conditions in question are: currently_stepping (ecs) && prev_pc != stop_pc - DECR_PC_AFTER_BREAK and (worse still): (currently_stepping (ecs) && prev_pc != stop_pc - DECR_PC_AFTER_BREAK && !(step_range_end && INNER_THAN (read_sp (), (step_sp - 16)))) Actually, I'm not convinced that the name "not a breakpoint" (whether they be software or otherwise) is a good characterization of these conditions. That said, I don't have a better suggestion. (My head hurts whenever I look at this code.) Kevin