Re: [RFC] symbol lookup cache

[Pedro Alves <palves at redhat dot com>]

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