struct environment

[Daniel Jacobowitz]

On Tue, Sep 17, 2002 at 03:47:36AM -0400, Andrew Cagney wrote:
> Btw, try ``struct nametab''?  These are just tables for mapping a name 
> onto a symbol?

Hmm..

> 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 :-).

Why do you think this will cause any bloat?  This is why David
suggested a model of block with a linear list implementation.

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

Well, sort of.  It won't be a DAG necessarily (I think that mutual
"using" statements are legal in C++; I remember a GCC bug involving
them was fixed not long ago), and it will be somewhat complicated
figuring out which ones to look up (namespace links are different than
block scope links).

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

At least iterate over all, search regexp.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer