From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25207 invoked by alias); 12 Sep 2002 18:18:16 -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 25200 invoked from network); 12 Sep 2002 18:18:15 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 12 Sep 2002 18:18:15 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17pZTh-0000YB-00; Thu, 12 Sep 2002 14:18:13 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17pYXn-0006rv-00; Thu, 12 Sep 2002 14:18:23 -0400 Date: Thu, 12 Sep 2002 11:18:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] environment.c Message-ID: <20020912181823.GA25787@nevyn.them.org> Mail-Followup-To: David Carlton , gdb-patches@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00203.txt.bz2 On Thu, Sep 12, 2002 at 11:10:55AM -0700, David Carlton wrote: > I'm more or less ready to start adding a 'struct environment' member > to struct block and making corresponding changes in the code, > following the process I outlined in > . > > I've written all the environment code, and I'll include that in the > bottom of this message. I've examined all the places where the > current GDB code refers to BLOCK_HASHTABLE, BLOCK_NSYMS, BLOCK_SYM, > BLOCK_BUCKETS, BLOCK_BUCKET, ALL_BLOCK_SYMBOLS, and BLOCK_SHOULD_SORT, > and I've tried to find all places where current GDB code creates a > struct block; I'm confident that it should be straightforward to make > the transition in all of those places. If anybody's curious, here are > the most distinctive special cases: > > * jv-lang.c and mdebugread.c both create blocks on their own, rather > than using buildsym.c. This is what the linear_expandable and > block_expandable implementations are for. > > * Some of the ada code seems to write an ALL_BLOCK_SYMBOLS by hand, > except that it jumps into the middle of the search. But it only > jumps into the middle if it tries to examine a sorted block and > finds that it needs to look at things more closely. Given that > BLOCK_SHOULD_SORT is becoming irrelevant, those uses should be able > to be currently replaced by ALL_BLOCK_SYMBOLS (and hence by the new > ALL_ENV_SYMBOLS). You may find the patch which added (and the separate patch to use it in a last few places, some months later) ALL_BLOC_SYMBOLS to be educational. They weren't too long ago. You're pretty much right about the Ada stuff; it's a mess but I didn't want to fix it at the time since Ada support still isn't compiled in (I think). I had to examine exactly the set of places you're looking at right now. Otherwise, looks reasonable. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer