From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8671 invoked by alias); 4 Mar 2006 18:01:03 -0000 Received: (qmail 8662 invoked by uid 22791); 4 Mar 2006 18:01:01 -0000 X-Spam-Check-By: sourceware.org Received: from gandalf.inter.net.il (HELO gandalf.inter.net.il) (192.114.186.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 04 Mar 2006 18:00:58 +0000 Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id IAX13990; Sat, 4 Mar 2006 20:00:52 +0200 (IST) Received: from HOME-C4E4A596F7 (IGLD-80-230-156-242.inter.net.il [80.230.156.242]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id CVC44013 (AUTH halo1); Sat, 4 Mar 2006 20:00:49 +0200 (IST) Date: Mon, 06 Mar 2006 19:49:00 -0000 Message-Id: From: Eli Zaretskii To: gdb-patches@sourceware.org In-reply-to: <20060304150514.GC20187@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 4 Mar 2006 10:05:14 -0500) Subject: Re: Save the length of inserted breakpoints Reply-to: Eli Zaretskii References: <20060303141123.GA8069@nevyn.them.org> <20060303175407.GA14450@nevyn.them.org> <20060303214359.GA20872@nevyn.them.org> <20060303221003.GA21606@nevyn.them.org> <20060304144330.GA20187@nevyn.them.org> <20060304150514.GC20187@nevyn.them.org> 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/msg00103.txt.bz2 > Date: Sat, 4 Mar 2006 10:05:14 -0500 > From: Daniel Jacobowitz > > On Sat, Mar 04, 2006 at 04:54:04PM +0200, Eli Zaretskii wrote: > > > Date: Sat, 4 Mar 2006 09:43:30 -0500 > > > From: Daniel Jacobowitz > > > > > > > > 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. > > > > > > > > Btw, is this division described anywhere? > > > > > > Yes, extensively, in gdbint. > > > > I looked there before asking, so please tell what is the section name > > that describes this. Sorry for being blind. > > They have their own chapters: Target Architecture Definition and Target > Vector Definition. Perhaps the titles could be clarified. > > GDB's target architecture defines what sort of machine-language > programs GDB can work with, and how it works with them. > > versus > > The target vector defines the interface between GDB's abstract handling > of target systems, and the nitty-gritty code that actually exercises > control over a process or a serial port. I saw these. The definition of the target vector is quite specific, while that of the architecture, IMNSHO, doesn't explain anything. In particular, the usual meaning of the word ``architecture'' does not go well with ``the sort of machine-language programs''. The fact that both terms use the word ``target'' (target architecture vs target vector) doesn't help, either. Perhaps a more elaborate description which lists at least the more important parts of the architecture and, respectively, the target vector, will make the docs better. Would someone ``in the know'' care to write it? > > > The CPSR support is turning out to be a remarkable pain for such a > > > simple change. > > > > That's why I thought we should discuss the design aspects here. > > Do you have any suggestions for the design? Well, you say that this issue is between the target and the architecture, so keeping the info in those layers seems like a good start. Does this make sense? > Heh... another way I could make the interface more symmetric would be > to bump up the size of the shadow contents vector, and have targets > which care about the size store the length in there when inserting > the breakpoint. Sounds a bit unclean to me.