From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20634 invoked by alias); 25 Jul 2006 18:40:56 -0000 Received: (qmail 20611 invoked by uid 22791); 25 Jul 2006 18:40:50 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 25 Jul 2006 18:40:39 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G5RpP-0004tc-D9; Tue, 25 Jul 2006 14:40:23 -0400 Date: Wed, 26 Jul 2006 01:21:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: Greg Law , gdb@sourceware.org Subject: Re: bfinish writes to random addresses. Message-ID: <20060725184023.GA18796@nevyn.them.org> Mail-Followup-To: Mark Kettenis , Greg Law , gdb@sourceware.org References: <44C63B23.7060306@undo-software.com> <20060725154115.GA13191@nevyn.them.org> <44C6405A.50502@undo-software.com> <20060725160914.GA14110@nevyn.them.org> <44C645C0.1050409@undo-software.com> <20303.82.92.89.47.1153851740.squirrel@webmail.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20303.82.92.89.47.1153851740.squirrel@webmail.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00187.txt.bz2 On Tue, Jul 25, 2006 at 08:22:20PM +0200, Mark Kettenis wrote: > > Daniel Jacobowitz wrote: > > > > > And there aren't very many hardware breakpoints, if any. > > > > At least in the cases I've seen on x86, most of the time the hardware > > breakpoints aren't in use. Of course, on other architectures there may > > be none, and on x86 they may all be used. But my point was that if a > > hardware breakpoint is used if available, it would fix this at least in > > those cases. > > If you can come up with some code that doesn't compicate matters too much > and falls back on the software breakpoints if no hardware breakpoints are > available, that might be a good idea. Fortunately, we already need code to do this sort of thing - and it's one of those issues that we (at CS) are going to be taking a look at this year, time permitting. This is just the reverse of trying to use a software breakpoint when debugging ROM, and the same approach will work. -- Daniel Jacobowitz CodeSourcery