Re: [rfc] struct dictionary

[David Carlton <carlton@math.stanford.edu>]

On Fri, 25 Apr 2003 11:31:35 -0400, Andrew Cagney <ac131313@redhat.com> said:

> Ok, humor me ...
> http://sources.redhat.com/ml/gdb/2003-04/msg00017.html why even
> build these data structures during symbol reading?  It takes time
> and space, yet is probably never used.  Why not on-demand build this
> dictionary specialized for the block?

That sounds great to me if we can get it to work.  It's certainly
another reason to try to get the symbol lookup stuff abstracted behind
an opaque interface: it makes lazy loading of data a lot easier.

About the mdebugread stuff: personally, I don't care about it in the
slightest, so I'm happy for its performance to degrade, and it seems
little-enough used that a 2x degradation is perfectly acceptable.
After all, if anybody really cares about it, there's an easy fix:
buildsym-ify it, so that it uses the same mechanisms everybody else
does.  Having said that, I've already done the work on my branch to
convert it to an efficient dictionary mechanism (using a combination
of hashed and unsorted linear representations); it really wasn't all
that much work.

As far as special cases go, I'm much more worried about the Java one:
the mechanism that Java uses for dynamically loaded classes is
extremely fragile, and only works through a chain of unintentional
coincidences.  Basically, it creates this block that is linear, isn't
sorted, but yet satisfies BLOCK_SHOULD_SORT, but there's special-case
code in all the symbol lookup functions to look through Java blocks
linearly instead of using sorting, where the stated reasons for doing
so are, I think, not correct, and where this one block for which it
actually _is_ necessary is never mentioned.

Also, I think that C++ could benefit from having a few special-purpose
blocks like Java does, because C++ classes and namespaces aren't
naturally tied to a single file.

David Carlton
carlton@math.stanford.edu