From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17528 invoked by alias); 16 Oct 2003 15:27:54 -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 17490 invoked from network); 16 Oct 2003 15:27:52 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 16 Oct 2003 15:27:52 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0BA0E2B89; Thu, 16 Oct 2003 11:27:53 -0400 (EDT) Message-ID: <3F8EB8F8.7040700@redhat.com> Date: Thu, 16 Oct 2003 15:27:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Simplify target stack References: <3F8DCC3A.4030201@redhat.com> <20031016131613.GB14202@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00542.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 I believe that the objectives here are: 1. being able to directly walk the target chain Makes it possible to eliminate the INHERIT mess. Lets targets efficiently/directly interact with target-beneath. 2. allow multiple instances of a specific target So that more than one target stack is possible. 3. strict separation of target instance and target ops See below. In terms of priority, I rank them as above. My immediate objective is the first one - make the target stack directly accessible. That way I can implement target read/write partial in a relatively clean way (the INHERIT in the current patch can go). It also comes with significant bang for the buck - it opens the way for an incremental cleanup of the target vectors. The second objective has to be considered medium term. Any direct references to static variables, and the currently static target ops will need to go. Fortunatly, it can be done on an as-needed basis. This change can be implemented out without worrying about the third objective - just clone the existing registered target vector when a new instance is required. For the last one, some background is needed. The original target code implemented the target ops using completly static structures Unfortunatly this proved to be un-maintainable - adding and removing fields broke things - and was replaced by runtime initialization (this is also one of the reasons behind the architecture vector using run-time initialization). While the code migh eventually be massaged into run-time initializing a separate "struct target_ops", I don't think its exactly urgent. enjoy, Andrew