From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5865 invoked by alias); 6 Sep 2002 22:00:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5827 invoked from network); 6 Sep 2002 22:00:00 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 6 Sep 2002 22:00:00 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g86M00018492; Fri, 6 Sep 2002 15:00:00 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: gdb Subject: Re: struct environment References: Content-Type: text/plain; charset=US-ASCII From: David Carlton Date: Fri, 06 Sep 2002 15:00:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 X-SW-Source: 2002-09/txt/msg00042.txt.bz2 On 05 Sep 2002 13:50:40 -0700, David Carlton said: > The question remains of how to get from here to there. I'm pretty > sure that I can convert 'struct block' over to using environments in > an incremental fashion. Describing that process will take a fair > amount of time, though, so I'll send it in a separate e-mail, > probably some time tomorrow but maybe Monday. Here's the basic idea as to how to convert struct block over to environments incrementally. As I commented before, environments will have various internal implementations. Current candidates for implementations are: * Fixed-size hash tables. * Fixed-size lists. * Some sort of growing implementation (necessary for jv-lang.c, alas). But while we're in the middle of converting over 'struct block', there will be one more implementation: * An implementation that keeps a pointer to a struct block, and does all lookups by accessing that struct block. The advantage of that latter implementation is that, given blocks whose environments use that implementation, all symbol lookups can be done either by the old-fashioned methods or by the new environment lookup methods, with identical results. So, broadly speaking, the implementation process will have three steps: 1) Convert existing block creators to use environments that are implemented via a pointer to 'struct block'. 2) Convert all block symbol lookups from the old accessors to the new accessors. 3) Convert the block creators to use one of the implementations other than 'struct block'. That's the basic idea. Here's the gory details: ** Step 0: Implement environments. Create a new file 'environment.c' to contain all of the environment-managing code. (Side note: I just realized that GDB already has a (little-used) 'struct environ' and a file 'environ.c'. Oops. If anybody thinks that adding 'struct environment' to this would create confusion and has a better name to suggest, I'm all ears.) Implement the various constructors/accessors/etc. for environments, for each of the various internal implementations mentioned above. (Actually, at this stage it's only necessary to implement the constructors for the 'struct block' internal implementation; the accessors could be deferred until just before step 2, and the other internal implementations could be deferred until just before step 3, if desired.) ** Step 1: Convert existing block creators to use environments that are implemented via a pointer to 'struct block'. So we start by adding a struct environment * member to struct block. Then, we have to make sure it gets initialized correctly, via an environment that points to the block in question. There are, I believe, 3 cases here: * The default case. This is for blocks allocated via buildsym.c. This should be straightforward to implement: the complete list of symbols to be added to the blocks is already known. * mdebugread.c. Frankly, my brain can't handle that file right now. I'll try looking at it again next week, but if somebody familiar with that file could give me an indication as to what is proper to do with it, I'd appreciate it. For all I know, it would be easy enough to convert it over to using the buildsym.c mechanisms; if not, I'll have to do some sort of special-case code for doing partially-constructed environments that then get finalized and hashed. * jv-lang.c. This constructs one separate block that can grow indefinitely. (It contains names of classes, and I see no particular reason that we'll ever be able to tell that we're done adding classes.) So this will need to use a special implementation. Each case should be dealt with by a single patch, and the three patches should be logically independent of each other. The first and third patches should be easy; it seems plausible to me that the mdebugread.c patch might be a pain in the neck. ** Step 2: Convert all block symbol lookups from the old accessors to the new accessors. At the end of step 1, the environment data in blocks should be able to be accessed in two different ways: either via the old mechanisms (BLOCK_HASHTABLE, BLOCK_NSYMS, BLOCK_SYM, BLOCK_BUCKETS, BLOCK_BUCKET, ALL_BLOCK_SYMBOLS, etc.) or via new mechanisms (env_lookup_shallow(), whatever iterators get decided upon, etc.) So the goal here is to track down every single reference to the old mechanisms and convert them to the new mechanisms. E.g. uses of ALL_BLOCK_SYMBOLS should be replaced by uses of a new macro which goes through the new iterators for the environment objects. Or lookup_block_symbol() will call env_lookup_shallow(). Indeed, calls to lookup_block_symbol() might be replaced to calls to env_lookup_shallow(); note, however, that Daniel Jacobowitz warns that I'll have to be careful with mangled vs. demangled names there, so lookup functions will have to handle that (and possibly there will need to be two different env_lookup_shallow functions). Also, in the middle of this, I'll probably delete all references to BLOCK_SHOULD_SORT, and all sorting of linear blocks. Blocks created by buildsym.c never satisfy BLOCK_SHOULD_SORT; block created in other ways can either be rewritten to be created by buildsym.c or just live with having unsorted linear environments. (Incidentally, the global block in jv-lang.c probably satisfies BLOCK_SHOULD_SORT, but I'm fairly sure it never gets sorted.) This step can be implemented by lots of patches in almost any order: either the old methods or the new methods work during this step, so there's no need to worry about being consistent here. ** Step 3: Convert the block creators to use one of the implementations other than 'struct block'. At the end of step 2, all lookups are going through the new accessors. So now the old accessors can be deleted; and then the code from step 1 can be converted over to using one of the permanent implementations, rather than using implementation via 'struct block'. Then the members hashtable, nsyms, and sym of 'struct block' can be removed. David Carlton carlton@math.stanford.edu