From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29828 invoked by alias); 12 Jan 2007 18:11:21 -0000 Received: (qmail 29819 invoked by uid 22791); 12 Jan 2007 18:11:21 -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 18:11:13 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.8/8.13.4) with ESMTP id l0CIB3GC021050; Fri, 12 Jan 2007 19:11:03 +0100 Received: from [192.168.1.2] (78.122.69-86.rev.gaoland.net [86.69.122.78] (may be forged)) (authenticated bits=0) by sophia.inria.fr (8.13.8/8.13.4) with ESMTP id l0CIB24O021041 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 12 Jan 2007 19:11:03 +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 18:11:00 -0000 Message-Id: <1168625474.29690.22.camel@mathieu> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-2.fc6) 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 19:11:03 +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/msg00217.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. hrm, I have actually tried to get the cvs version of gdb to use hw breakpoints using this 'automatic' conversion but failed to ever get it to trigger. Is there a way to make gdb print the target memory map it uses to make this decision ? I tried the following: (gdb) info mem Using memory regions provided by the target. There are no memory regions defined. (gdb) Which leads me to suspect that my current target (x86 linux FC6) does not implement this so, the memory region lookup code returns the default region all the time which contains an RW attr. Is this expected ? Did I somehow screw up the configuration stage ? regards, Mathieu