From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28302 invoked by alias); 9 Feb 2002 17:34:41 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28235 invoked from network); 9 Feb 2002 17:34:40 -0000 Received: from unknown (HELO localhost.redhat.com) (24.114.26.18) by sources.redhat.com with SMTP; 9 Feb 2002 17:34:40 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 5DE673E6A; Sat, 9 Feb 2002 12:34:37 -0500 (EST) Message-ID: <3C655DAD.3040706@cygnus.com> Date: Sat, 09 Feb 2002 09:34:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: jimb@cygnus.com, Michael Snyder Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: RFA: Elaborate on new overlay support References: <20020208192755.8882C5E9DE@zwingli.cygnus.com> <2593-Sat09Feb2002094444+0200-eliz@is.elta.co.il> <1858-Sat09Feb2002184407+0200-eliz@is.elta.co.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00276.txt.bz2 > From: Jim Blandy >> Date: 09 Feb 2002 11:17:46 -0500 >> >> Are you sure this is the right thing? How breakpoints are implemented >> is usually completely hidden from the user. > > > Not completely: we have the "hbreak" command, for example. > > If you meant to tell that even "break" sometimes sets a hardware > breakpoint, then I agree that it's an internal GDB matter, but if > those are the cases you refer to here, there's no need to explain at > length what hardware breakpoints are, just make a cross-reference to > the "Breakpoints" node, where the detailed explanation should live. Er, yes. I think there is something more basic going on here. The hbreak VS break command question comes up irregularly. Should ``break'' be allowed to set hardware breakpoints? My memory of the rationale for separate break and hbreak commands is that the hardware breakpoint is (at least traditionally) very scarce. Consequently the user is given complete and explicit control over them. This allowing the user to carefully allocate those valueable resources to things like a breakpoint on that ROM. Software breakpoints on the other hand were cheap. They do come with certain implied semantics. They work by modifying memory in the target and hence move around when the target moves their memory around. If this isn't happening then I would argue it isn't a software breakpoint. I get the feeling that there are two issues lurking here: -- Firstly there looks to be a bug in the software-breakpoint packet. Consider the sequence: set software breakpoint at 0xdead program resumes program copies *0xdead to *0xbeef program stops GDB knows (via the overlay table) that there is a breakpoint at both FOO and BAR. Removing the breakpoint at foo is easy: z0,dead,4 Removing the breakpoint at ``beef'' though is impossible. GDB knows what memory should be at that location. The target doesn't - the target can't track where the breakpoint is (that is unless the target also starts tracking overlays). I guess this suggests that when a software breakpoint is set, it returns the original memory value, and when cleared, that original memory value is included in the packet. I remember this being suggested at the time (I think so that the target didn't need to record the replaced memory?), sigh. -- Secondly it looks like there is a broken target. As noted above, a software breakpoint has certain implied semantics (it works by modifying target memory). A target implementing software breakpoints using a hardware breakpoint mechanisms, I think, is broken - it has broken the contract it made with GDB. Presumably such a target has an infinite (or nearly so) number of hardware breakpoints and so doesn't see any point in using software-breakpoints. While OK, this decision needs to be communicated back to GDB so that GDB knows what is really going on. The old ``never lie'' rule applies. enjoy, Andrew