This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] symbol lookup cache
- From: Pedro Alves <palves at redhat dot com>
- To: Doug Evans <dje at google dot com>, gdb-patches at sourceware dot org, brobecker at adacore dot com
- Date: Thu, 04 Dec 2014 16:38:30 +0000
- Subject: Re: [RFC] symbol lookup cache
- Authentication-results: sourceware.org; auth=none
- References: <yjt2y4qrlqwa dot fsf at ruffy dot mtv dot corp dot google 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