Re: struct environment

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Sep 06, 2002 at 03:34:34PM -0400, Daniel Berlin wrote:
> 
> 
> > one which might not even be necessary (see below).
> > 
> > >> And there's another, even more important reason: the global
> > >> environment (and, in the future, namespaces).  The global
> > >> environment spans multiple files, uses lazy evaluation
> > >> (i.e. partial_symbols), and there's even minimal_symbols to
> > >> shoehorn in there somehow.  So it's going to need its own special
> > >> implementation (which will be much more complicated than the
> > >> implementations for blocks).
> > 
> > > This is why I don't like the environment == list-of-symbols thing.
> > > An environment may HAVE a list of symbols, but it is not its list of
> > > symbols.  You shouldn't grow the list of symbols in the global
> > > environment when a new file is added.  Instead you should associate
> > > a new list of symbols with it.
> 
> This makes lookup dependent on two things, instead of one (number of 
> files, and number of names, vs number of names).
> Bad idea when you can avoid it.
> If you want to know what blocks go with which files, than store *that* 
> information.
> Removal is *not* the common case.

Well, what I had in mind when I wrote that was the same sort of thing
you originally described - with a cached mapping of symbols -> blocks. 
I do need to sit down and think about how namespaces interact here
however... gets a little peculiar.


> Note that this wasn't the first time someone wanted to do this.  HP has a 
> whole "FAT_FREE_PSYMTABS" thing in WDB.

Yeah.  Killing psymtabs in general would be nice but that's tabled
behind stub methods (which I am slowing quashing).

What's the current status of the location expression stuff, by the
way?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer