From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21837 invoked by alias); 4 Dec 2014 19:17:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21821 invoked by uid 89); 4 Dec 2014 19:17:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-vc0-f178.google.com Received: from mail-vc0-f178.google.com (HELO mail-vc0-f178.google.com) (209.85.220.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 04 Dec 2014 19:17:50 +0000 Received: by mail-vc0-f178.google.com with SMTP id hq11so8406698vcb.9 for ; Thu, 04 Dec 2014 11:17:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lQcNdcHvCxE3d3bpjfIYFtu2p/MNzE7i76LoeTOsn5Q=; b=UmpDX7lCPizXrRNTjPBnKWbZC/b36Vjrf1zeuuUe6AnJs+YoJFHmNLLTFagu62wGmw 8nuOjqp8Xnza6l6P+rLnwZt+1rUZ3OrrgffBr+ibU9AJPaKd5KtphXaXk7Ke42IcyeGR 2mUW9uX0+J3yBr6vAxFgF0IrygEEBes5Mp2PGVpch5BAva2ckaatyjOUx7tnrcE1pi4b KXIIAphbW0l3MFN6OmlT7X2KsJcN0V9+jaQ4ODwTzFgqGw+w/j9fFnOBFxw8hzdmH8Jx QDlDOCcRpfwdEcHvnNZKzK9gUyacw6ygJvQx+gQPa3BnRJM8WujMjhaMpXtAbP6t9YKq suAg== X-Gm-Message-State: ALoCoQmCdBigKW8LrPy4JqadLFAknB2wnkUDPD7z8veXy6ZvOXoMk7RC/L3YGx5568KTOpUlDyzc MIME-Version: 1.0 X-Received: by 10.220.102.20 with SMTP id e20mr6474543vco.12.1417720668136; Thu, 04 Dec 2014 11:17:48 -0800 (PST) Received: by 10.52.114.101 with HTTP; Thu, 4 Dec 2014 11:17:48 -0800 (PST) In-Reply-To: <54808E06.9040200@redhat.com> References: <54808E06.9040200@redhat.com> Date: Thu, 04 Dec 2014 19:17:00 -0000 Message-ID: Subject: Re: [RFC] symbol lookup cache From: Doug Evans To: Pedro Alves Cc: gdb-patches , Joel Brobecker Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00109.txt.bz2 On Thu, Dec 4, 2014 at 8:38 AM, Pedro Alves 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.