From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5716 invoked by alias); 24 Mar 2009 20:33:08 -0000 Received: (qmail 5706 invoked by uid 22791); 24 Mar 2009 20:33:07 -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 20:33:02 +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 n2OKWwwU015096; Tue, 24 Mar 2009 13:32:59 -0700 Message-ID: <49C94379.3020206@tensilica.com> Date: Tue, 24 Mar 2009 20:33: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> In-Reply-To: <20090324165732.GA7928@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/msg00145.txt.bz2 Daniel Jacobowitz wrote: >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. > > I think you're saying it's not a big deal performance-wise to do this without a remote protocol extension. Is that correct? I think it's quite possible to implement the target-specific macro STOPPED_BY_PROGRAM_BREAKPOINT(size) without any help from the remote protocol. That is certainly an option, and might be the method of choice for non-remote targets and some remote targets. Having the remote stub do the break detection has other benefits. It removes the burden of parsing the set of possible instructions that *might* cause a stop, from GDB, and lets the stub (which has already decided to signal a stop) simply tell GDB why it stopped. It also handles cases where the stub decides whether to stop or not based on factors beyond the instruction itself. Seems cleaner and more robust. In general I think SIGTRAP is too overloaded in GDB which has to jump through hoops to figure out why it stopped. What I'm hoping to get from this RFC is whether the community would accept this method, or whether it would rather take another approach (before I put in more effort to simplify our solution and submit it). We'd like to have a solution that we don't have to keep merging. :-) I'll wait a few more days in case others have something to say. Thanks, Ross