[RFC] symbol lookup cache

[Doug Evans]

On Thu, Dec 4, 2014 at 8:38 AM, Pedro Alves <palves@redhat.com> wrote:
>
> On 12/01/2014 08:23 AM, Doug Evans wrote:
> > Hi.
> >
> > Holidays are nice for having the time to take on
> > projects one is interested in but doesn't have
> > time to otherwise do.
> >
> > I looked at a couple of areas for improvement
> > in gdb's symbol handling over the last couple
> > of days.  One is .gdb_index support for tab
> > completion, which is the topic for another mail.
> > This email is about a symbol lookup cache.
> >
> > ..gdb_index helps speed things up for one objfile,
> > but when there are 100s (or 1000s) of shared
> > libraries, symbol lookup can still take awhile,
> > even with .gdb_index.
> > [I'm setting aside a planned change to basic
> > symbol lookup to use the index better.
> > We'll still, I think, want a cache even
> > with that change.]
> >
> > This patch still needs more testing
> > and I need to collect more perf data,
> > but it's a start at caching symbol lookups.
> > This first pass is just for the case
> > where we iterate over all objfiles for
> > lookups in the global or static blocks.
> > Low hanging fruit.
> > At the moment it's just RFC.
>
> I don't have particular comments on the patch, but a cache in
> principle sounds like a great idea to me.
>
> You've probably thought this through already, but, my only worry
> is whether this could affect which symbol is found.  E.g., if
> there are multiple instances of a static global symbol in the
> program.  ISTR expressions find the instance in the current
> module (or CU?) first.  I may be thinking of solib_global_lookup.
> Could the cache hit the symbol in another module first?
>
> Thanks,
> Pedro Alves
>


Oh curse you gmail.  Sorry for the resend.

The intent is to perform the caching only from lookups after all
context-specific searches have been done.
E.g, we specifically do lookups in the current STATIC_BLOCK (via
lookup_symbol_in_static_block) and then call the
"loop-over-all-static-blocks" routine (lookup_static_symbol), and it's
only the latter that employs caching.
context-specific searches are generally pretty quick and
don't(/shouldn't) need caching.

I put the caching checks after the call to solib_global_lookup in
lookup_global_symbol to avoid problems there.
Alas, I'm guessing it's windows's global search routine
(windows_iterate_over_objfiles_in_search_order) that is going to throw
a wrench into the works here.
We'll need to refactor that.
Seems like we have two solutions (solib_global_lookup and
gdbarch_iterate_over_objfiles_in_search_order) for what is essentially
the same problem.