From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23190 invoked by alias); 24 Mar 2009 20:40:03 -0000 Received: (qmail 23178 invoked by uid 22791); 24 Mar 2009 20:40:02 -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 20:39:57 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 09ACA1018A; Tue, 24 Mar 2009 20:39:55 +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 9736510183; Tue, 24 Mar 2009 20:39:54 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1LmDPd-00005g-GC; Tue, 24 Mar 2009 16:39:53 -0400 Date: Tue, 24 Mar 2009 20:40:00 -0000 From: Daniel Jacobowitz To: Ross Morley Cc: gdb@sourceware.org Subject: Re: RFC: Program Breakpoints Message-ID: <20090324203953.GA309@caradoc.them.org> Mail-Followup-To: Ross Morley , gdb@sourceware.org References: <49C7BDD6.3060305@tensilica.com> <20090324165732.GA7928@caradoc.them.org> <49C94379.3020206@tensilica.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C94379.3020206@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/msg00146.txt.bz2 On Tue, Mar 24, 2009 at 01:32:57PM -0700, Ross Morley wrote: >> 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. >> >> > > I think you're saying it's not a big deal performance-wise to do this > without a remote protocol extension. Is that correct? No, I was saying the opposite. Sometimes it will still be expensive to implement the protocol extension. I'm interested in whether anyone sees an approach that does not require instruction scanning. GDB has the option to cheat - it can consult the program (ELF file), separately from the target's view of memory. This would not work for stray breakpoints inserted in the program at runtime, though. -- Daniel Jacobowitz CodeSourcery