From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7515 invoked by alias); 16 Aug 2002 19:34:11 -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 7508 invoked from network); 16 Aug 2002 19:34:10 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 16 Aug 2002 19:34:10 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0A5273C8D; Fri, 16 Aug 2002 15:34:08 -0400 (EDT) Message-ID: <3D5D53AF.1000908@ges.redhat.com> Date: Fri, 16 Aug 2002 12:34:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/ob] not_a_breakpoint -> not_a_sw_breakpoint References: <3D5D1C3E.8070203@ges.redhat.com> <1020816164312.ZM11179@localhost.localdomain> <3D5D37A7.2090003@ges.redhat.com> <1020816185159.ZM30848@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00446.txt.bz2 >> 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.) I think that is separate. The ``intent'' of the variable is to indicate that what is being looked at isn't a trap due to a software breakpoint event. > 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 Yes, see my e-mail to Joel. I'm asking that a separate explict ``trap_from_software_singlestep'' be ||ed into those equations. While the rest might be pretty bogus (the above is just an heuristic really) at least that flag will be correct :-) Andrew