From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29517 invoked by alias); 6 Mar 2006 19:49:38 -0000 Received: (qmail 29509 invoked by uid 22791); 6 Mar 2006 19:49:38 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Mar 2006 19:49:36 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k26JnX42030261; Mon, 6 Mar 2006 14:49:33 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k26JnW123889; Mon, 6 Mar 2006 14:49:32 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k26JnUmG027086; Mon, 6 Mar 2006 14:49:30 -0500 Message-ID: <440C9249.2000707@redhat.com> Date: Tue, 07 Mar 2006 05:31:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sourceware.org Subject: Re: Save the length of inserted breakpoints References: <20060302221711.GB18830@nevyn.them.org> <200603022301.k22N1qEt008208@elgar.sibelius.xs4all.nl> <20060303141123.GA8069@nevyn.them.org> <20060303175407.GA14450@nevyn.them.org> <20060303214359.GA20872@nevyn.them.org> In-Reply-To: <20060303214359.GA20872@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00106.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Mar 03, 2006 at 11:39:30PM +0200, Eli Zaretskii wrote: > >>>Date: Fri, 3 Mar 2006 12:54:07 -0500 >>>From: Daniel Jacobowitz >>>Cc: gdb-patches@sourceware.org >>> >>>If every target cached the size of inserted breakpoints and made sure >>>to remove them at the same size, that would work too, but right now >>>most targets don't need to remember anything about the breakpoints >>>they've inserted; the common layer of GDB handles it. >> >>That sounds like an unfortunate design. If we are to make significant >>changes to handle the complications that led you to this patch, >>perhaps we should consider changing the design instead. > > > Well, as I said, I was trying to not redesign more of GDB than > necessary... > > Do you believe it _should_ be the target vector's responsibility to > remember inserted breakpoint details? I find this a little bit > strange, since every target will have to do just about the > same thing. That's not unusual, though. Just means that we export a "default" method, and targets that need to do it differently can override the default. Not weighing in on the question, mind you... > Another possible interface change to solve the problem would be to > pass a "struct breakpoint" to the remove function. However, today > there are many places where breakpoints are used without a > corresponding "struct breakpoint" e.g. for software single step. > I've tried cleaning up that in the past, and it's defeated me > every single time. >