Re: [RFC] environment.c

[Daniel Jacobowitz <drow@mvista.com>]

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
> <http://sources.redhat.com/ml/gdb/2002-09/msg00042.html>.
> 
> 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