From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29267 invoked by alias); 12 Jan 2007 14:27:06 -0000 Received: (qmail 29253 invoked by uid 22791); 12 Jan 2007 14:27:04 -0000 X-Spam-Check-By: sourceware.org Received: from centrmmtao05.cox.net (HELO centrmmtao05.cox.net) (70.168.83.79) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 Jan 2007 14:26:56 +0000 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao05.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070112142654.WQYH11822.centrmmtao05.cox.net@eastrmimpo01.cox.net>; Fri, 12 Jan 2007 09:26:54 -0500 Received: from black ([70.181.32.198]) by eastrmimpo01.cox.net with bizsmtp id AERW1W0074GV2Jm0000000; Fri, 12 Jan 2007 09:25:30 -0500 Received: from bob by black with local (Exim 4.62) (envelope-from ) id 1H5NMr-0007vE-0E; Fri, 12 Jan 2007 09:26:53 -0500 Date: Fri, 12 Jan 2007 14:27:00 -0000 From: Bob Rossi To: Mathieu Lacage Cc: Daniel Jacobowitz , gdb@sourceware.org Subject: Re: help string for "break" command Message-ID: <20070112142652.GB5540@cox.net> References: <1168602087.2789.35.camel@garfield.inria.fr> <1168606081.2789.38.camel@garfield.inria.fr> <1168609517.2789.47.camel@garfield.inria.fr> <20070112134932.GA21726@nevyn.them.org> <1168611571.2789.53.camel@garfield.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1168611571.2789.53.camel@garfield.inria.fr> User-Agent: Mutt/1.5.12-2006-07-14 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00215.txt.bz2 On Fri, Jan 12, 2007 at 03:19:31PM +0100, Mathieu Lacage wrote: > On Fri, 2007-01-12 at 08:49 -0500, Daniel Jacobowitz wrote: > > On Fri, Jan 12, 2007 at 02:45:16PM +0100, Mathieu Lacage wrote: > > > Am I right in assuming that the gdb command "break" places exclusively > > > so-called software-breakpoints while the command "hbreak" places a > > > hardware-breakpoint (I am not sure I have figured out the details of the > > > logic in gdb/breakpoint.c) ? > > > > Not 100%. CVS versions of GDB will use hardware breakpoints > > automatically if you try to set them in truly read-only memory. > > I see the following comment in the CVS version: > /* If the explicitly specified breakpoint type > is not hardware breakpoint, check the memory map to see > if the breakpoint address is in read only memory or not. > Two important cases are: > - location type is not hardware breakpoint, memory > is readonly. We change the type of the location to > hardware breakpoint. > - location type is hardware breakpoint, memory is read-write. > This means we've previously made the location hardware one, but > then the memory map changed, so we undo. > > When breakpoints are removed, remove_breakpoints will > use location types we've just set here, the only possible > problem is that memory map has changed during running program, > but it's not going to work anyway with current gdb. */ > > and it seems to match the decision logic I see below. > > Would there be opposition to an 'sbreak' command which would ensure that > a software breakpoint is used _all the time_ ? Is the 'set breakpoint auto-hw off' helpful here? http://sourceware.org/gdb/current/onlinedocs/gdb_6.html#SEC32 Bob Rossi