From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24977 invoked by alias); 24 Mar 2009 23:59:51 -0000 Received: (qmail 24969 invoked by uid 22791); 24 Mar 2009 23:59:51 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hq2.tensilica.com (HELO maia.hq.tensilica.com) (65.205.227.30) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Mar 2009 23:59:47 +0000 Received: from [172.16.150.11] (nose.hq.tensilica.com [172.16.150.11]) (authenticated bits=0) by maia.hq.tensilica.com (8.13.1/8.13.1) with ESMTP id n2ONxgEu013006; Tue, 24 Mar 2009 16:59:42 -0700 Message-ID: <49C973EE.8060702@tensilica.com> Date: Tue, 24 Mar 2009 23:59:00 -0000 From: Ross Morley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sourceware.org Subject: Re: RFC: Program Breakpoints References: <49C7BDD6.3060305@tensilica.com> <20090324165732.GA7928@caradoc.them.org> <49C94379.3020206@tensilica.com> <20090324203953.GA309@caradoc.them.org> In-Reply-To: <20090324203953.GA309@caradoc.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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/msg00149.txt.bz2 Daniel Jacobowitz wrote: >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. > Sorry for the misunderstanding. >Sometimes it will still be expensive >to implement the protocol extension. > I would think that in most cases the stub already knows something about what's going on, be it a single-step trap, a data watchpoint match, or a breakpoint. It already has to distinguish some of those cases. In many if not most cases the stub gets an exception directed to a certain vector, an indication in a status register, or some other clue as to the nature of the stop. It doesn't need to distinguish types of break instruction except for size (if there's more than one). It also needn't distinguish GDB planted breaks from program breaks. If a target finds it's too expensive to implement the remote protocol extension, then that target can have GDB probe the instruction. >I'm interested in whether anyone >sees an approach that does not require instruction scanning. > > I suspect it's going to be very target and arch specific. >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. > > Not always. Program breaks are often very useful in situations where you have code embedded in a ROM and no ELF file available. We put them in exception handlers to allow a debugger to get control when certain exceptions happen. I do agree it would be good to hear if anyone has any other ideas. Thanks, Ross