From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30787 invoked by alias); 3 Mar 2006 22:10:09 -0000 Received: (qmail 30778 invoked by uid 22791); 3 Mar 2006 22:10:09 -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; Fri, 03 Mar 2006 22:10:05 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FFITL-0005dS-CZ for gdb-patches@sourceware.org; Fri, 03 Mar 2006 17:10:03 -0500 Date: Fri, 03 Mar 2006 23:01:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: Save the length of inserted breakpoints Message-ID: <20060303221003.GA21606@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/msg00087.txt.bz2 On Sat, Mar 04, 2006 at 12:01:00AM +0200, Eli Zaretskii wrote: > > I find this a little bit strange, since every target will have to do > > just about the same thing. > > We could have a generic method that most of them could use. Those > that have peculiarities, such as those which started this thread, will > have to provide their own methods. For the record, it is not a target with peculiarities. It's an architecture with a feature (that on the order of four other GDB-supported architectures have). There's a division in GDB between the target, which is a method of communication et cetera ("how"), and the architecture, which describes "what" is being debugged. It's a quirk of the architecture (all of the architectures, although none of the others do this sort of heuristic today) that there are multiple sizes of breakpoints and we can't statically determine which one we need. It's a requirement of most targets that we know how big a breakpoint is when inserting or removing it. The architecture says "the breakpoint at 0x8000 should be 2 bytes long". The target sets the breakpoint. The target goes to remove the breakpoint, and needs to know how long it was when it was set. If it were contained within either a target or an architecture, the solution would obviously be much smaller. -- Daniel Jacobowitz CodeSourcery