[RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

>> - macro's are bad m'kay :-)
> 
> 
> Even accessor macros for members of structures?  Gee, I like those:
> it's a lot easier to find all places where, say, struct block's
> 'hashtable' member is being used by grepping for 'BLOCK_HASHTABLE'
> than by grepping for 'hashtable' and then sorting out which ones of
> those really are referring to the 'hashtable' member as opposed to
> some other use of the phrase.

Yep.  If you think accessor macro's are a good idea, try debugging / 
using sim/common some time :-(

Also grep -e '->hashtable' works pretty well.

> Admittedly, that's less important here since the structures in
> question are opaque, so they'll only be accessed within one file.  So
> if you want me to move away from them, that's fine; I was just trying
> to follow existing practice in symtab.h and gdbtypes.h.

Have a look at more recent code such as regcache.h.

 > ALL_DICT_SYMBOLS; but I'm happy to get rid of that since the interface


> The macros that are currently used (as seen in
> <http://sources.redhat.com/ml/gdb-patches/2002-09/msg00202.html>,
> modulo replacing 'environment' by 'dictionary', not just in the
> smaller portion of it that I recently put up for RFA) fit (I think!)
> into the following taxonomy:
> 
> * One-argument accessor macros for members of structures.
> * Two-argument accessor macros for members of structures that are
>   arrays: these accessor macros take the index into the array as a
>   second argument.
> * Symbolic constants.
> * ALL_DICT_SYMBOLS, to make looping over all the symbols easier.
> 
> I think the only macro that is publically accessible is
> ALL_DICT_SYMBOLS; but I'm happy to get rid of that since the interface
> to iterating over symbols in dictionaries is a lot easier than the
> interface to iterating over symbols in blocks.

The ALL_xxx_yyy() iterator can probably stay.  Its an ``accepted'' 
convention.

> So if you want me to get rid of all macros (other than, presumably,
> symbolic constants, though I could use the enum trick there), I can
> certainly do that.

Yes, please.  Symbolic constants as enum's is recommended.

>> - just implement interfaces sufficient for the immediate needs.  For
>>   instance, instead of providing ``enum dict_type'', just describe
>>   the idea.  Since we can compile with -Werror, changing internal
>>   interface, when there is evidence that it is actually needed, has
>>   become relativly easy.

> dict_type really is necessary currently: I need to provide hash tables
> and linear environments to support the existing functionality of
> blocks.  It's just like the 'hashtable' member of struct block.

Then just mention those that do apply.
(I thought DanielJ indicated that you just doing an initial linear 
implementation?)

>> - keep gdbint.texinfo in mind
> 
> 
> Right.
> 
> 
>> - you'll want to start compiling all targets
> 
> 
> Sure.  How do I go about doing this?  I don't have access to a wide
> range of machines; are there machines at Red Hat that I can use?

target's not hosts :-)  There is some sed in MAINTAINERS for generating 
the target list.  Richard E, I believe, posted a script for doing all 
the config's and builds.

Andrew