This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



- 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]