From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 364 invoked by alias); 2 Mar 2006 23:10:47 -0000 Received: (qmail 356 invoked by uid 22791); 2 Mar 2006 23:10:46 -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; Thu, 02 Mar 2006 23:10:44 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FEwwU-0005rO-AL; Thu, 02 Mar 2006 18:10:42 -0500 Date: Thu, 02 Mar 2006 23:19:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: Save the length of inserted breakpoints Message-ID: <20060302231042.GA22458@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20060302221711.GB18830@nevyn.them.org> <200603022301.k22N1qEt008208@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603022301.k22N1qEt008208@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-03/txt/msg00063.txt.bz2 On Fri, Mar 03, 2006 at 12:01:52AM +0100, Mark Kettenis wrote: > > Date: Thu, 2 Mar 2006 17:17:11 -0500 > > From: Daniel Jacobowitz > > > > This nasty, mechanical patch adds "len" arguments to > > target_remove_breakpoint and target_remove_hw_breakpoint. The goal is > > to allow BREAKPOINT_FROM_PC to include heuristics, which may possibly > > change between when a breakpoint is inserted and when it is removed; > > in order to stay in sync, we need to always remove breakpoints in the > > same way that we inserted them. > > > > There's not much more to say about this patch. It's big, obvious, and > > pretty ugly. Any comments on this? Does it look OK? > > Yuck! It really is ugly. For one thing, I think it is a bit > pointless, to add a the BREAKPOINT_FROM_PC() to targets where we know > the length of a breakpoint instruction is fixed. > > Another thing is that I think the order of the arguments of > target_remove_breakpoint() is wrong. I think it makes sense to see > your "len" argument as the length of the saved memory. Then it is > more logical to make "len" the last argument of > target_remove_breakpoint(). > > However, doesn't it make more sense to have target_insert_breakpoint() > save the length instead of using BREAKPOINT_FROM_PC() to ask for it? If you want me to do that, I'll do that instead. It requires touching twice as many target functions. Writing the changelog for this one took long enough, so forgive me if I wait a while before trying it again :-) -- Daniel Jacobowitz CodeSourcery