From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28697 invoked by alias); 31 Jan 2004 17:51:32 -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 28687 invoked from network); 31 Jan 2004 17:51:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 31 Jan 2004 17:51:31 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AmzHH-0001Vp-EF for ; Sat, 31 Jan 2004 12:51:31 -0500 Date: Sat, 31 Jan 2004 17:51:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFC: Centralize DECR_PC_AFTER_BREAK handling from infrun Message-ID: <20040131175131.GB5154@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20040117222007.GA23563@nevyn.them.org> <20040118151909.GA17039@nevyn.them.org> <3791-Sun18Jan2004192337+0200-eliz@elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3791-Sun18Jan2004192337+0200-eliz@elta.co.il> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00778.txt.bz2 On Sun, Jan 18, 2004 at 07:23:38PM +0200, Eli Zaretskii wrote: > > Date: Sun, 18 Jan 2004 10:19:10 -0500 > > From: Daniel Jacobowitz > > > > > > What happens if a location has both software and hardware > > > breakpoints? Does the code still DTRT? > > > > Hmm, I am not sure. What _is_ the right thing? > > We should at least do no worse than the current code does--which is to > act as if only the first breakpoint (in the order stored in the > breakpoint data-base) were hit. That is, if breakpoints #n and #m > both fire, the current GDB announces the one whose number is smaller > (because it walks thru the breakpoints in their numerical order). It > doesn't seem to matter whether the breakpoints are of the software or > the hardware-assisted variety. > > It would be nice if we could announce all breakpoints that break at > that point, but this might not be possible or very hard, I dunno. Behavior unchanged by this patch. Only one of the breakpoints will be inserted - the other will be marked as a duplicate - and only inserted breakpoints are checked when figuring out whether a software breakpoint was hit. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer