From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30434 invoked by alias); 17 Apr 2006 21:50:32 -0000 Received: (qmail 30417 invoked by uid 22791); 17 Apr 2006 21:50:32 -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 21:50:30 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FVbc2-00070A-DZ; Mon, 17 Apr 2006 17:50:26 -0400 Date: Mon, 17 Apr 2006 21:50: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: <20060417215026.GA26596@nevyn.them.org> Mail-Followup-To: Mark Kettenis , msnyder@redhat.com, gdb-patches@sourceware.org References: <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> <20060417133748.GA15525@nevyn.them.org> <200604171349.k3HDnTlG026394@elgar.sibelius.xs4all.nl> <20060417190808.GA22372@nevyn.them.org> <200604172024.k3HKO6Y3002093@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604172024.k3HKO6Y3002093@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/msg00223.txt.bz2 On Mon, Apr 17, 2006 at 10:24:06PM +0200, Mark Kettenis wrote: > Hmm, if I understand things correctly, the only reason why you need > placed_size, is because we want shadow_len to tell is whether we've > actually saved the contents or not. This is eh, a wee bit ugly. Correct (on both counts). > Actually I think the z0 packet should not include the length of the > breakpoint. The remote stub will have to keep track of the length of > the inserted breakpoint anyway, exactly because it has get the the > target memory correct. Yes... and no. Two problems with that, which I'm sure you can see. One is that, in practice, it's there; we can't remove it (protocol incompatibilities), and because it's there, stub developers probably use it. They may have to stash this information somewhere else, but not use that copy when actually removing the breakpoint. Ugh! [Actually I bet a lot of stubs DON'T get the underlying memory correct, which makes their dependence on this even clearer. I bet a lot of stubs would report the breakpoint. Most of the time, we read memory with breakpoints removed, so a lot of stub authors may just not have noticed this issue - and there's nothing about it in the manual. It might be more pragmatic to always issue the read, but I'm reluctant unless we find real problems with it; why double the number of packets needlessly?] And secondly, software breakpoints seem to be such a simple concept... but the variety of ways people find to implement them is astounding. For instance, you would not need to record the length if you could "shadow" executing ROM pages using RAM; you could perform memory reads from the ROM page, and insert breakpoints onto the RAM page. > I'm still thinking about a more elegant solution. One would be to > allocate the shadow contents dynamically and make it a NULL pointer if > GDB didn't actually save any shadow contents. Meanwhile, I spropose > you check this in. This issue has been on the table long enough now. Thanks for your understanding. If you find a nicer way, I'll pitch in to help clean up the result. In the mean time, we'll go with this version. I'm going to wait a little longer - I'd appreciate Eli's look over the gdbint.texi bits, and I'm out of my GDB work environment at the moment so I can't test it. > P.S. Someone should really get rid of tm-sh.h and > DEPRECATED_{BIG|LITTLE}_BREAKPOINT. That's not all that someone should get rid of... -- Daniel Jacobowitz CodeSourcery