This is the mail archive of the gdb@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: struct environment


On Friday, September 6, 2002, at 03:41  PM, Daniel Jacobowitz wrote:

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?
I've been too busy with law school and interviews (2nd year law students have interviews for summer jobs in late august and early september. Absurd, no?) to work on it.
I did make sure Peter Sofa and Jim Blandy know this, and that if they want it done anytime soon, to work on it themselves.
The changes Jim requested probably wouldn't take more than a day or two to implement, i just don't have that day or two right now.

--
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer







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