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

Andrew Cagney
2002-09-17T19:16:54Z

>> - 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