DW_AT_specification and partial symtabs

DW_AT_specification and partial symtabs

[David Carlton]

One of the main issues that I'm dealing with on my branch is getting
nested types to work right in C++ (with DWARF 2): these have the
characteristic that they depend on the hierarchical structure of the
debug info to a greater extent than, as far as I can tell, anything
that mainline GDB currently does.  The reason for this is that, to
deduce a nested type's name, you really have to know where it lives in
the hierarchical structure, so you can add whatever prefixes are
appropriate to its DW_AT_name.  (With non-types, we (over)use mangled
names for this sort of thing, so it's not such a big deal there.)

For example, a couple of weeks ago I fixed a bug on the branch where I
wasn't setting the names of types mentioned via DW_AT_type properly.
(I introduced parent pointers in the symtab reader's tree of DIEs so
we could get at that information.)  Today I want to deal with the fact
that DW_AT_specification can lead you to hop around the tree of DIEs.

This was already going to be a little messy, but then I realized that
this issue affects not only symtabs but also psymtabs.  Specifically,
say we have code like this:

  namespace N {
    class C;
  }

  class N::C {
  public:
    int foo;
  };

Then a compiler might choose to create a DW_TAG_namespace die for N
whose child is a DW_TAG_class_type die for C that's just a
declaration; then, outside of the DIE for N, it might have a
DW_TAG_class_type die for N::C that gives the actual definition but
has a DW_AT_specification that points at the declaration for C within
N.  Schematically:

1) comp unit DIE
  2) die for N
    3) declaration for N::C
  4) definition of N::C (with specification pointing to 3)

Then the only way that we'll know that C lives within N (and hence
should be called N::C instead of just C) is by following that
DW_AT_specification (to die 3) and realizing that it is a child of die
2.

Unfortunately, there's no way to get at that information at all with
the current psymtab reader: it tries to march from top-level DIE to
top-level DIE without building up a tree of DIEs.  So it seems to me
that I have no choice but to have the psymtab reader build up a tree
of DIEs before it starts reading, just like the symtab reader does.

Comments?  Suggestions?  Ideas for how to make the tree that the
psymtab reader builds to be as small as possible?  I'm a little
worried about weird cases like local classes: if I have

  void foo ()
  {
    class Local {
    public:
      int mem() {return 1;}
    };

    ...
  }

then is the compiler allowed to put a definition of Local::mem as a
child of the comp unit die (with a DW_AT_specification pointing to a
DIE inside of foo somewhere)?

David Carlton
carlton@kealia.com

Re: DW_AT_specification and partial symtabs

[Daniel Jacobowitz]

On Thu, Jun 12, 2003 at 10:01:38AM -0700, David Carlton wrote:
> One of the main issues that I'm dealing with on my branch is getting
> nested types to work right in C++ (with DWARF 2): these have the
> characteristic that they depend on the hierarchical structure of the
> debug info to a greater extent than, as far as I can tell, anything
> that mainline GDB currently does.  The reason for this is that, to
> deduce a nested type's name, you really have to know where it lives in
> the hierarchical structure, so you can add whatever prefixes are
> appropriate to its DW_AT_name.  (With non-types, we (over)use mangled
> names for this sort of thing, so it's not such a big deal there.)

> Unfortunately, there's no way to get at that information at all with
> the current psymtab reader: it tries to march from top-level DIE to
> top-level DIE without building up a tree of DIEs.  So it seems to me
> that I have no choice but to have the psymtab reader build up a tree
> of DIEs before it starts reading, just like the symtab reader does.
> 
> Comments?  Suggestions?  Ideas for how to make the tree that the
> psymtab reader builds to be as small as possible?  I'm a little
> worried about weird cases like local classes: if I have

I'll answer this in more depth in a bit.  For now, something to
consider: I would like to add .debug_typenames (spelling?) to GCC -
it's an SGI extension, IIRC.  This plus .debug_pubnames should allow us
to implement psymtabs entirely without mapping .debug_info.  I believe
it handles your case too, since it should have fully qualified
typenames.

The implementation may need a little tweaking for space efficiency...

>   void foo ()
>   {
>     class Local {
>     public:
>       int mem() {return 1;}
>     };
> 
>     ...
>   }
> 
> then is the compiler allowed to put a definition of Local::mem as a
> child of the comp unit die (with a DW_AT_specification pointing to a
> DIE inside of foo somewhere)?

I believe so.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DW_AT_specification and partial symtabs

[David Carlton]

On Thu, 12 Jun 2003 13:05:45 -0400, Daniel Jacobowitz <drow@mvista.com> said:

> I'll answer this in more depth in a bit.  For now, something to
> consider: I would like to add .debug_typenames (spelling?) to GCC -
> it's an SGI extension, IIRC.

Yes.  It's actually .debug_pubtypes, and has made it into the DWARF 3
spec.  (Though the description there could use some work.)

I don't think that I'm too likely to do that myself, though, for
various reasons.

>> void foo ()
>> {
>> class Local {
>> public:
>> int mem() {return 1;}
>> };
>> 
>> ...
>> }
>> 
>> then is the compiler allowed to put a definition of Local::mem as a
>> child of the comp unit die (with a DW_AT_specification pointing to a
>> DIE inside of foo somewhere)?

> I believe so.

Ulgh.  That's what I think, too.

David Carlton
carlton@math.stanford.edu

Re: DW_AT_specification and partial symtabs

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Thu, Jun 12, 2003 at 10:01:38AM -0700, David Carlton wrote:
 > > One of the main issues that I'm dealing with on my branch is getting
 > > nested types to work right in C++ (with DWARF 2): these have the
 > > characteristic that they depend on the hierarchical structure of the
 > > debug info to a greater extent than, as far as I can tell, anything
 > > that mainline GDB currently does.  The reason for this is that, to
 > > deduce a nested type's name, you really have to know where it lives in
 > > the hierarchical structure, so you can add whatever prefixes are
 > > appropriate to its DW_AT_name.  (With non-types, we (over)use mangled
 > > names for this sort of thing, so it's not such a big deal there.)
 > 
 > > Unfortunately, there's no way to get at that information at all with
 > > the current psymtab reader: it tries to march from top-level DIE to
 > > top-level DIE without building up a tree of DIEs.  So it seems to me
 > > that I have no choice but to have the psymtab reader build up a tree
 > > of DIEs before it starts reading, just like the symtab reader does.
 > > 
 > > Comments?  Suggestions?  Ideas for how to make the tree that the
 > > psymtab reader builds to be as small as possible?  I'm a little
 > > worried about weird cases like local classes: if I have
 > 

I wonder, if we are not reaching the end of the usefulness of the
psymtabs.  I mean, if we start making the psymtab reader behave like
the symtab reader, how much faster is that going to be, how much
smaller, etc. 
I need to go reread the old threads on this.

elena



 > I'll answer this in more depth in a bit.  For now, something to
 > consider: I would like to add .debug_typenames (spelling?) to GCC -
 > it's an SGI extension, IIRC.  This plus .debug_pubnames should allow us
 > to implement psymtabs entirely without mapping .debug_info.  I believe
 > it handles your case too, since it should have fully qualified
 > typenames.
 > 
 > The implementation may need a little tweaking for space efficiency...
 > 
 > >   void foo ()
 > >   {
 > >     class Local {
 > >     public:
 > >       int mem() {return 1;}
 > >     };
 > > 
 > >     ...
 > >   }
 > > 
 > > then is the compiler allowed to put a definition of Local::mem as a
 > > child of the comp unit die (with a DW_AT_specification pointing to a
 > > DIE inside of foo somewhere)?
 > 
 > I believe so.
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: DW_AT_specification and partial symtabs

[David Carlton]

On Thu, 12 Jun 2003 13:26:51 -0400, Elena Zannoni <ezannoni@redhat.com> said:

> I wonder, if we are not reaching the end of the usefulness of the
> psymtabs.  I mean, if we start making the psymtab reader behave like
> the symtab reader, how much faster is that going to be, how much
> smaller, etc. 

Yeah, I'm starting to wonder that, too.  This particular situation is
enough of an edge case that I'm actually tempted not to fix the
psymtab reader until I get bug reports from users complaining about
it, because if I do fix it completely then I'll probably make the
psymtab reader slow, make it duplicate lots and lots of the
functionality of the symtab reader, and do it in such a way as to
cause code duplication that will lead to bugs as the two versions slip
out of sync.  So I'm tempted to let things be for now, and wait until
.debug_pubtypes comes along to save the day.

I guess another possibility would be to merge the symtab reader and
psymtab reader, and have there be some variable 'reading_psyms' or
whatever to control what sort of symbols we're creating, how deeply we
descend into trees, etc.

It would be interesting to find out the following:

1) How much is the savings for building a psymtab vs. building a
   symtab?

2) Where is that savings coming from?

If the savings largely comes from not descending into the bodies of
functions, then the current structure should go: we should just merge
the psymtab and symtab readers, but have some flag floating around
that controls whether or not we descend into bodies of functions.

David Carlton
carlton@math.stanford.edu

Re: DW_AT_specification and partial symtabs

[Daniel Jacobowitz]

On Thu, Jun 12, 2003 at 03:16:58PM -0700, David Carlton wrote:
> On Thu, 12 Jun 2003 13:26:51 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> 
> > I wonder, if we are not reaching the end of the usefulness of the
> > psymtabs.  I mean, if we start making the psymtab reader behave like
> > the symtab reader, how much faster is that going to be, how much
> > smaller, etc. 
> 
> Yeah, I'm starting to wonder that, too.  This particular situation is
> enough of an edge case that I'm actually tempted not to fix the
> psymtab reader until I get bug reports from users complaining about
> it, because if I do fix it completely then I'll probably make the
> psymtab reader slow, make it duplicate lots and lots of the
> functionality of the symtab reader, and do it in such a way as to
> cause code duplication that will lead to bugs as the two versions slip
> out of sync.  So I'm tempted to let things be for now, and wait until
> .debug_pubtypes comes along to save the day.
> 
> I guess another possibility would be to merge the symtab reader and
> psymtab reader, and have there be some variable 'reading_psyms' or
> whatever to control what sort of symbols we're creating, how deeply we
> descend into trees, etc.
> 
> It would be interesting to find out the following:
> 
> 1) How much is the savings for building a psymtab vs. building a
>    symtab?
> 
> 2) Where is that savings coming from?
> 
> If the savings largely comes from not descending into the bodies of
> functions, then the current structure should go: we should just merge
> the psymtab and symtab readers, but have some flag floating around
> that controls whether or not we descend into bodies of functions.

1) is very easy to measure.  GDB has a command line option --readnow
which forces symtabs to be read in immediately.  I tried my normal
performance testcase: a dummy main() linked to all of mozilla's
component libraries, with full stabs debug info.  Note stabs, not
DWARF2, so the timing may vary.  Also note that we duplicate psymtab
and symtab creation doing it this way, so it overestimates the cost. 
But it should give you an idea.

Psymbols 5.3:
gdb --batch -x a ./mozilla-libs  17.34s user 1.72s system 78% cpu 24.160 total

Psymbols and symbols 5.3:
gdb --batch -x a ./mozilla-libs --readnow  41.20s user 4.93s system 83% cpu 55.207 total

Psymbols CVS:
/opt/src/gdb/x86-as/gdb/gdb --batch -x a ./mozilla-libs  8.79s user 1.01s system 99% cpu 9.850 total

Psymbols and symbols CVS:
/opt/src/gdb/x86-as/gdb/gdb --batch -x a ./mozilla-libs --readnow 30.45s user 2.70s system 94% cpu 35.131 total

Note that none of those times is really acceptably fast, IMHO.  Probably
they all can be improved.  Looking at profiling data I see about three
seconds we can knock off the symbol reader and there are almost
certainly more.

Andrew's suggested in the past that (rather than all-at-once) we read
symbols lazily; that's essentially like the status quo but without a
separate psymtab table.  I don't know how much that saves us.

Keep in mind that symbols are (at present) rather memory-intensive
compared to psymbols.  Also keep in mind that we build more type
information when reading symbols - more time, more memory.

One quick thing we can do to speed up DWARF2 symbol reading is to
finish converting the rest of GDB to runtime-computed locations; then
we won't have to parse location lists or location expressions at
load time.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DW_AT_specification and partial symtabs

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Thu, Jun 12, 2003 at 03:16:58PM -0700, David Carlton wrote:
 > > On Thu, 12 Jun 2003 13:26:51 -0400, Elena Zannoni <ezannoni@redhat.com> said:
 > > 
 > > > I wonder, if we are not reaching the end of the usefulness of the
 > > > psymtabs.  I mean, if we start making the psymtab reader behave like
 > > > the symtab reader, how much faster is that going to be, how much
 > > > smaller, etc. 
 > > 
 > > Yeah, I'm starting to wonder that, too.  This particular situation is
 > > enough of an edge case that I'm actually tempted not to fix the
 > > psymtab reader until I get bug reports from users complaining about
 > > it, because if I do fix it completely then I'll probably make the
 > > psymtab reader slow, make it duplicate lots and lots of the
 > > functionality of the symtab reader, and do it in such a way as to
 > > cause code duplication that will lead to bugs as the two versions slip
 > > out of sync.  So I'm tempted to let things be for now, and wait until
 > > .debug_pubtypes comes along to save the day.
 > > 
 > > I guess another possibility would be to merge the symtab reader and
 > > psymtab reader, and have there be some variable 'reading_psyms' or
 > > whatever to control what sort of symbols we're creating, how deeply we
 > > descend into trees, etc.
 > > 
 > > It would be interesting to find out the following:
 > > 
 > > 1) How much is the savings for building a psymtab vs. building a
 > >    symtab?
 > > 
 > > 2) Where is that savings coming from?
 > > 
 > > If the savings largely comes from not descending into the bodies of
 > > functions, then the current structure should go: we should just merge
 > > the psymtab and symtab readers, but have some flag floating around
 > > that controls whether or not we descend into bodies of functions.
 > 
 > 1) is very easy to measure.  GDB has a command line option --readnow
 > which forces symtabs to be read in immediately.  I tried my normal
 > performance testcase: a dummy main() linked to all of mozilla's
 > component libraries, with full stabs debug info.  Note stabs, not
 > DWARF2, so the timing may vary.  Also note that we duplicate psymtab
 > and symtab creation doing it this way, so it overestimates the cost. 
 > But it should give you an idea.
 > 
 > Psymbols 5.3:
 > gdb --batch -x a ./mozilla-libs  17.34s user 1.72s system 78% cpu 24.160 total
 > 
 > Psymbols and symbols 5.3:
 > gdb --batch -x a ./mozilla-libs --readnow  41.20s user 4.93s system 83% cpu 55.207 total
 > 
 > Psymbols CVS:
 > /opt/src/gdb/x86-as/gdb/gdb --batch -x a ./mozilla-libs  8.79s user 1.01s system 99% cpu 9.850 total
 > 
 > Psymbols and symbols CVS:
 > /opt/src/gdb/x86-as/gdb/gdb --batch -x a ./mozilla-libs --readnow 30.45s user 2.70s system 94% cpu 35.131 total
 > 
 > Note that none of those times is really acceptably fast, IMHO.  Probably
 > they all can be improved.  Looking at profiling data I see about three
 > seconds we can knock off the symbol reader and there are almost
 > certainly more.

But with --readnow we do both psymtabs and symtabs. I wonder, if we
didn't do psymtabs at all, the time would improve, one hopes.
And the memory footprint would shrink too.

 > 
 > Andrew's suggested in the past that (rather than all-at-once) we read
 > symbols lazily; that's essentially like the status quo but without a
 > separate psymtab table.  I don't know how much that saves us.
 > 
 > Keep in mind that symbols are (at present) rather memory-intensive
 > compared to psymbols.  Also keep in mind that we build more type
 > information when reading symbols - more time, more memory.
 > 
 > One quick thing we can do to speed up DWARF2 symbol reading is to
 > finish converting the rest of GDB to runtime-computed locations; then
 > we won't have to parse location lists or location expressions at
 > load time.
 > 

yes, that's a clear win.

elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: DW_AT_specification and partial symtabs

[Andrew Cagney]

Daniel wrote:


>  > 1) is very easy to measure.  GDB has a command line option --readnow
>  > which forces symtabs to be read in immediately.  I tried my normal
>  > performance testcase: a dummy main() linked to all of mozilla's
>  > component libraries, with full stabs debug info.  Note stabs, not
>  > DWARF2, so the timing may vary.  Also note that we duplicate psymtab
>  > and symtab creation doing it this way, so it overestimates the cost. 

I think that's an understatement.

Elena wrote:

> But with --readnow we do both psymtabs and symtabs. I wonder, if we
> didn't do psymtabs at all, the time would improve, one hopes.
> And the memory footprint would shrink too.

Some back of envelope caculations are in order.

``(gdb) print sizeof (struct ...) indicates that sizeof(symtab) ~= 
2*sizeof(psymtab) so GDB is burning 33% of allocated memory.  Assuming 
memory and file I/O are the bottle neck, slashing 33% of memory should 
slash 33% of the time.

I just hope GDB isn't doing something stupid like searching psymtab 
before symtab.

>  > Note that none of those times is really acceptably fast, IMHO.  Probably
>  > they all can be improved.  Looking at profiling data I see about three
>  > seconds we can knock off the symbol reader and there are almost
>  > certainly more.

I think oprofile data would be far more useful - remember the thread 
problem where the profile data (and its suggested micro-optimizations) 
were totally bogus.  But having said that, wasn't there a proposal to 
fix/rewrite BFD's mmap interface?

I think what's needed is a proper comparison of the current contents of 
the symbol tabe VS exactly what and how often GDB requests that info. 
For dwarf2, for instance, it now reads in all the location expression 
stuff, and that, relatively speaking, is never used.

If psymtab's are dumped (or at least burried) the core GDB <-> symtab 
interface is simplified/tightened, people can change the internals 
without breaking everything. David, I belive, has been working in that 
direction.

Andrew

Re: DW_AT_specification and partial symtabs

[Daniel Jacobowitz]

On Fri, Jun 13, 2003 at 11:38:38AM -0400, Andrew Cagney wrote:
> Daniel wrote:
> 
> 
> > > 1) is very easy to measure.  GDB has a command line option --readnow
> > > which forces symtabs to be read in immediately.  I tried my normal
> > > performance testcase: a dummy main() linked to all of mozilla's
> > > component libraries, with full stabs debug info.  Note stabs, not
> > > DWARF2, so the timing may vary.  Also note that we duplicate psymtab
> > > and symtab creation doing it this way, so it overestimates the cost. 
> 
> I think that's an understatement.

Not really.  You can subtract the psymtab time from the combined time,
and then compare.  It still more than triples the time.

> Elena wrote:
> 
> >But with --readnow we do both psymtabs and symtabs. I wonder, if we
> >didn't do psymtabs at all, the time would improve, one hopes.
> >And the memory footprint would shrink too.
> 
> Some back of envelope caculations are in order.
> 
> ``(gdb) print sizeof (struct ...) indicates that sizeof(symtab) ~= 
> 2*sizeof(psymtab) so GDB is burning 33% of allocated memory.  Assuming 
> memory and file I/O are the bottle neck, slashing 33% of memory should 
> slash 33% of the time.
> 
> I just hope GDB isn't doing something stupid like searching psymtab 
> before symtab.

That neglects type information, which we don't really build during
psymtab reading, and is a huge memory sink.

> > > Note that none of those times is really acceptably fast, IMHO.  Probably
> > > they all can be improved.  Looking at profiling data I see about three
> > > seconds we can knock off the symbol reader and there are almost
> > > certainly more.
> 
> I think oprofile data would be far more useful - remember the thread 
> problem where the profile data (and its suggested micro-optimizations) 

Ah, but you can back-of-the-envelope simulate this easily without
oprofile.  Build without -pg, use maint set profile.  It does only flat
profiling using a timer, and is fairly accurate.

> were totally bogus.  But having said that, wasn't there a proposal to 
> fix/rewrite BFD's mmap interface?

Yes, but who knows when it'll happen.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DW_AT_specification and partial symtabs

[Andrew Cagney]

> 
> Ah, but you can back-of-the-envelope simulate this easily without
> oprofile.  Build without -pg, use maint set profile.  It does only flat
> profiling using a timer, and is fairly accurate.

It lacks the system side and that is critical to a proper analysis.

Andrew

Re: DW_AT_specification and partial symtabs

[Andrew Cagney]

> On Fri, Jun 13, 2003 at 11:38:38AM -0400, Andrew Cagney wrote:
> 
>> Daniel wrote:
>> 
>> 
> 
>> > > 1) is very easy to measure.  GDB has a command line option --readnow
>> > > which forces symtabs to be read in immediately.  I tried my normal
>> > > performance testcase: a dummy main() linked to all of mozilla's
>> > > component libraries, with full stabs debug info.  Note stabs, not
>> > > DWARF2, so the timing may vary.  Also note that we duplicate psymtab
>> > > and symtab creation doing it this way, so it overestimates the cost. 
> 
>> 
>> I think that's an understatement.
> 
> 
> Not really.  You can subtract the psymtab time from the combined time,
> and then compare.  It still more than triples the time.

So we agree, 25% is significant but 3% is not.

A better question is what % of symtabs get draged in by a C++ `break 
main; run'.  Wasn't the original conjecture that symtabs get sucked in 
anyway so why do it twice.

Remember, as we've discovered with threads, users define ``GDB is slow 
to start'' differently to us as GDB developers.  We think of it as:

	$ gdb program
	(gdb)

but the user appears to be more focused on things like:

	(gdb) break main

and:

	(gdb) run
	Break point main reached
	(gdb)

The first can be really badly fudged by not even loading the [p]symtab . 
  Just makes `break main' a bit slow :-)

So, we really don't know what symtab info is critical to GDB.  An 
uneducated guess, based on ``break main; run'' is:

	- addr -> line
	- function/symbol -> addr
	- addr -> symbol

Andrew

Re: DW_AT_specification and partial symtabs

[Daniel Jacobowitz]

On Fri, Jun 13, 2003 at 12:23:53PM -0400, Andrew Cagney wrote:
> >On Fri, Jun 13, 2003 at 11:38:38AM -0400, Andrew Cagney wrote:
> >
> >>Daniel wrote:
> >>
> >>
> >
> >>> > 1) is very easy to measure.  GDB has a command line option --readnow
> >>> > which forces symtabs to be read in immediately.  I tried my normal
> >>> > performance testcase: a dummy main() linked to all of mozilla's
> >>> > component libraries, with full stabs debug info.  Note stabs, not
> >>> > DWARF2, so the timing may vary.  Also note that we duplicate psymtab
> >>> > and symtab creation doing it this way, so it overestimates the cost. 
> >
> >>
> >>I think that's an understatement.
> >
> >
> >Not really.  You can subtract the psymtab time from the combined time,
> >and then compare.  It still more than triples the time.
> 
> So we agree, 25% is significant but 3% is not.
> 
> A better question is what % of symtabs get draged in by a C++ `break 
> main; run'.  Wasn't the original conjecture that symtabs get sucked in 
> anyway so why do it twice.

I am pretty sure that the conjecture is false.  I've fixed several
things in this area.

I run GDB on target boards, over NFS root, with limited RAM, and full
debug info for libc and libstdc++.  When I mess up lazy loading, I
_notice_.  At least I'm not working on the 3MHz FPGA right now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DW_AT_specification and partial symtabs

[David Carlton]

On Fri, 13 Jun 2003 11:38:38 -0400, Andrew Cagney
<ac131313@redhat.com> said:

> If psymtab's are dumped (or at least burried) the core GDB <->
> symtab interface is simplified/tightened, people can change the
> internals without breaking everything. David, I belive, has been
> working in that direction.

Yeah.  I was thinking about this a little bit over the weekend (albeit
while not at a computer, so I haven't actually looked at GDB's source
code): from the point of view of looking up symbols by names, I don't
think we have too far to go.  If memory serves me well, the only
functionality that I haven't encapsulated in that regard is symbol
completion and regexp matching.  It would be easy to add methods for
those two to the dictionary interface; once we do that, I think there
would be no particular technical barrier to hiding the psymtab aspect
of name lookup inside the dictionaries.

Though it would take some restructuring of code elsewhere to actually
achieve this: right now, dictionaries live in blocks, and blocks live
in symtabs, not psymtabs.  So if we really want to start getting rid
of psymtabs, we'd have to rethink the symtab/psymtab data structures
themselves, so there's just one place to look for information of
various sorts.  (Which would presumably involve turning them opaque as
well.)  Still, it's a start.

It would be an interesting exercise to think about what interface this
new opaque symtab data structure would export, and how much of that
interface could be implemented lazily in the DWARF 2 case...

David Carlton
carlton@math.stanford.edu