From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23746 invoked by alias); 12 Jan 2007 14:20:21 -0000 Received: (qmail 23736 invoked by uid 22791); 12 Jan 2007 14:20:20 -0000 X-Spam-Check-By: sourceware.org Received: from sophia.inria.fr (HELO sophia.inria.fr) (138.96.64.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 Jan 2007 14:20:14 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.8/8.13.4) with ESMTP id l0CEJsOR017970; Fri, 12 Jan 2007 15:19:54 +0100 Received: from garfield.inria.fr (garfield.inria.fr [138.96.88.66]) (authenticated bits=0) by sophia.inria.fr (8.13.8/8.13.4) with ESMTP id l0CEJVod017843 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 12 Jan 2007 15:19:31 +0100 Subject: Re: help string for "break" command From: Mathieu Lacage To: Daniel Jacobowitz Cc: gdb@sourceware.org In-Reply-To: <20070112134932.GA21726@nevyn.them.org> 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> Content-Type: text/plain Date: Fri, 12 Jan 2007 14:20:00 -0000 Message-Id: <1168611571.2789.53.camel@garfield.inria.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Fri, 12 Jan 2007 15:19:31 +0100 (MET) 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/msg00213.txt.bz2 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_ ? Mathieu --