From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32517 invoked by alias); 24 Mar 2009 16:57:41 -0000 Received: (qmail 32509 invoked by uid 22791); 24 Mar 2009 16:57:40 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Mar 2009 16:57:36 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D55911018B; Tue, 24 Mar 2009 16:57:33 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id ACF7A10183; Tue, 24 Mar 2009 16:57:33 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1Lm9wS-00024F-EM; Tue, 24 Mar 2009 12:57:32 -0400 Date: Tue, 24 Mar 2009 16:57:00 -0000 From: Daniel Jacobowitz To: Ross Morley Cc: gdb@sourceware.org Subject: Re: RFC: Program Breakpoints (was: [RFC] stepping over permanent breakpoint) Message-ID: <20090324165732.GA7928@caradoc.them.org> Mail-Followup-To: Ross Morley , gdb@sourceware.org References: <49C7BDD6.3060305@tensilica.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C7BDD6.3060305@tensilica.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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: 2009-03/txt/msg00142.txt.bz2 On Mon, Mar 23, 2009 at 09:50:30AM -0700, Ross Morley wrote: > It was interesting to see the matter of skipping permanent breakpoints > come up on this list. This is very similar to an issue we dealt with > a couple of years ago with Xtensa and remote targets. Our solution > has been stable for at least two years, but has not yet been prepared > for submission because I've had higher priorities (and at that time we > were way out of sync with mainline GDB). The issue is actually more > complicated than the forgoing discussion suggests. > > I'd like to discuss it here and present our solution. I'll attach a > patch for our current solution relative to GDB 6.8, but I do propose > to revise it to improve some areas based on our experience (in the > next few weeks) - I'll discuss that toward the end of this post. I read through this; overall, it looks sane. On some targets implementing this would require the remote stub to read from pc anyway; that's faster than GDB doing it, but not necessarily much faster. But on some other targets the stub has to do this anyway, or can pipeline it with other necessary operations, so it's not a big loss. -- Daniel Jacobowitz CodeSourcery