This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: struct environment
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