From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12923 invoked by alias); 16 Oct 2003 13:16:14 -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 12915 invoked from network); 16 Oct 2003 13:16:14 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Oct 2003 13:16:14 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AA7zB-0003mg-U8 for ; Thu, 16 Oct 2003 09:16:13 -0400 Date: Thu, 16 Oct 2003 13:16:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Simplify target stack Message-ID: <20031016131613.GB14202@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <3F8DCC3A.4030201@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8DCC3A.4030201@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00538.txt.bz2 On Wed, Oct 15, 2003 at 06:37:46PM -0400, Andrew Cagney wrote: > Hello, > > The attached patch simplifies the target-stack by folding the "struct > target_stack_item" into the "struct target_ops". The field "struct > target_ops . beneath" being added. > > This in turn greatly simplifies the logic needed to walk the target > stack (target_beneath becomes a one-liner), and that in turn lets me > correctly implement the new target read/write partial methods I just posted. > > Note that this implementation is still limited to a single target stack > (due to all the target_ops vectors being static). Follow-on changes can > eliminate that restriction. > > Once I've finished testing, I'll look to commit it in a day or so, > Andrew You're moving beneath into target_ops, but aren't you going to have to either move it out again or move everything else from target_ops? It seems to me that we want the method vector to be constant eventually (kill the INHERIT mess), but the target to have local data. Just seems like this is happening in the wrong order. Another way would be: - rename target_ops and target_item - make access to target go through the renamed version of target_item - add a target_data member to the renamed target_data Other than that seems good. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer