struct environment

[Andrew Cagney]

David,

Per the original thread, this should be prototyped on a branch (you can 
then cut your self loose for a bit :-).

Having done this for regcache and reggroup it is worth it -> you get to 
see what actually works rather than what everyone else thinks should 
work.  You can also pick out the cleanups that will make the final 
change easier.  For instance - tightening up the way GDB creates symbol 
tables (DanielB suggested moving psymtab into stabs) an performs lookups 
on them.

--

Btw, try ``struct nametab''?  These are just tables for mapping a name 
onto a symbol?

--

Have a look at how I've been evolving ``struct frame_info'' and ``struct 
cmd_list_element[?]'':

- tighten up the existing interface so that you know how things are 
really used (rather than how you think things are used).  My trick was 
to do a temp rename of a field and then convert to accessor methods 
anything that didn't compile.

- with a tight interface, re-implement the internals.

--

Having also gone over the original thread, two things come to mind:

- what effect will this have on GDB's foot print?  The original proposal 
was to put these things everwhere (structs, unions, ...).  I don't think 
that is necessary and would cause serious bloat.  Instead, initially, I 
think these tables could be simple linear lists (that is what ``struct 
block'' currently implements so it can't be any worse :-) (just the 
global / final table is special :-).

- Am I correct to think that the objective is to create a directed 
acyclic graph of nametabs and have lookups search through each in turn.

--

In terms of operations, I would concentrate on determing exactly GDB 
needs (rather than you think it needs)   GDB is 15 years old so chance 
has it the operations have been identified already.  I know of two 
operations off hand:
	print foo
which gets turned into struct symbol *lookup("foo",``block'') and,
	print foo<tab>
which turns into ``const char **tabexpand("foo", ``block'')''.  Any others?

Andrew