From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23434 invoked by alias); 12 Apr 2006 18:47:25 -0000 Received: (qmail 23422 invoked by uid 22791); 12 Apr 2006 18:47:23 -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; Wed, 12 Apr 2006 18:47:20 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FTkN3-0007r3-JE; Wed, 12 Apr 2006 14:47:17 -0400 Date: Wed, 12 Apr 2006 18:47:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: Save the length of inserted breakpoints Message-ID: <20060412184717.GA29980@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20060302221711.GB18830@nevyn.them.org> <200603022301.k22N1qEt008208@elgar.sibelius.xs4all.nl> <20060411214613.GA702@nevyn.them.org> <200604120943.k3C9hYJ8012016@elgar.sibelius.xs4all.nl> <20060412125712.GA22145@nevyn.them.org> <200604121837.k3CIbMwu004466@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604121837.k3CIbMwu004466@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00153.txt.bz2 On Wed, Apr 12, 2006 at 08:37:22PM +0200, Mark Kettenis wrote: > > Would a new "struct bp_target_info", defined and allocated centrally > > for convenience, allay this concern? [Conveniently I can do the bulk > > of the changes for that with sed :-)] > > Why hide things away if all you're going to need is a buffer and a > length? I've tried really hard to see why one would need more than > that, but failed completely. > > So I think we should have: > > int target_insert_breakpoint(CORE_ADDR addr, gdb_byte *buf, int *size); > int target_remove_breakpoint(CORE_ADDR addr, gdb_byte *buf, int size); And then if you come up with a reason, you're going to need to hand edit every one of these targets again. It's not a bundle of fun. Is that really necessary? You need an address because the address at which the breakpoint is inserted may not match the requested address. This happens in several different places in the breakpoint infrastructure (I believe I counted three disjoint hooks for it), but I am particularly looking at BREAKPOINT_FROM_PC, which takes the PC by reference. In the ARM case, given 0x4001, it strips the low bit off and returns a two byte breakpoint. If we don't allow the target to save the actually-inserted-at address, then it has to call BREAKPOINT_FROM_PC again. It feels much more robust to me to save this address when we initially adjust it. Here's where we inserted the breakpoint, so that's where we should remove it from. I can think of plenty of other places where another constant might be useful. You might want to record which hardware breakpoint registers were used, for instance, instead of digging around to figure out which ones to clear. Adding a new member to "struct bp_target" for that would be easy. -- Daniel Jacobowitz CodeSourcery