From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32525 invoked by alias); 17 Apr 2006 13:37:57 -0000 Received: (qmail 32517 invoked by uid 22791); 17 Apr 2006 13:37:56 -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; Mon, 17 Apr 2006 13:37:54 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FVTvI-00042z-BI; Mon, 17 Apr 2006 09:37:48 -0400 Date: Mon, 17 Apr 2006 13:37:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: msnyder@redhat.com, gdb-patches@sourceware.org Subject: Re: Save the length of inserted breakpoints Message-ID: <20060417133748.GA15525@nevyn.them.org> Mail-Followup-To: Mark Kettenis , msnyder@redhat.com, gdb-patches@sourceware.org References: <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> <20060412184717.GA29980@nevyn.them.org> <443EC947.9060109@redhat.com> <200604162349.k3GNnNhl006336@elgar.sibelius.xs4all.nl> <20060417014133.GA4169@nevyn.them.org> <200604171308.k3HD8qdY014104@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604171308.k3HD8qdY014104@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/msg00216.txt.bz2 On Mon, Apr 17, 2006 at 03:08:52PM +0200, Mark Kettenis wrote: > But this means that actually we should try to make the interface > stricter, instead of looser. And the fact that the shadow contents > are needed makes it impossible to use an opaque struct. That in > combination with the possibility that BREAKPOINT_FROM_PC adjusts the > breakpoint address means that besides the length we also need to pass > back the address. At that point indeed passing a struct is perhaps a > better option. And we should remove the usage of BREAKPOINT_FROM_PC > from deprecated_read_memory_nobpt() altogether. Yes, absolutely - that's how I plan to fix it. > I still think we should maintain a strict seperation between the > high-level breakpoint code and the low-level target code. So I'd > really appreciate it if you'd be willing to change your patch such > that instead of struct bp_location, you used a different struct, which > for now would have three members: the saved contents, the length and > the address. It's perfectly ok with me to make that new struct part > of struct bp_location to avoid all memory allocation problems. Sounds perfect! While the argument was a little wearing, I am entirely happy with this result. I'll post a patch for this shortly. I've been thinking about having target methods which don't need the shadow contents (there are definitely several) record the "length" of the breakpoint as zero; then deprecated_read_memory_nobpt can do the right thing. Does this sound reasonable? The alternative is to do an unnecessary read from the target. -- Daniel Jacobowitz CodeSourcery