From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16004 invoked by alias); 9 May 2012 20:40:49 -0000 Received: (qmail 15801 invoked by uid 22791); 9 May 2012 20:40:45 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO,TW_BJ X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 May 2012 20:40:32 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 689781C6AA2; Wed, 9 May 2012 16:40:31 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oHpuyb6en4kz; Wed, 9 May 2012 16:40:31 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 3623E1C6AA1; Wed, 9 May 2012 16:40:31 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 80173145616; Wed, 9 May 2012 13:40:23 -0700 (PDT) Date: Wed, 09 May 2012 20:40:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFA] choose symbol from given block's objfile first. Message-ID: <20120509204023.GM15555@adacore.com> References: <1336430581-11262-1-git-send-email-brobecker@adacore.com> <874nrqvbeh.fsf@fleche.redhat.com> <20120509190529.GI15555@adacore.com> <20120509190753.GA31769@adacore.com> <87ehqtru0d.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ehqtru0d.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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 X-SW-Source: 2012-05/txt/msg00318.txt.bz2 > It looks reasonable to me, but I wonder whether it is complete. > That is -- there are a lot of uses of ALL_OBJFILES; I wonder whether any > of them need updating. I did a second audit, and found that a lot of those uses were for purposes other than symbol lookup (finding the symtab associated a PC, for instance), so an update shouldn't be needed there. There are a couple of places where the loop is used to find symbols, but collects all matching symbols instead of the first one. There are also some locations where the loop is inside a routine that does a lookup without "context". For instance, basic_lookup_transparent_type. In that case, the only real caller I could find was check_typedef, which I don't think we want to change. Then, there are the symtab iterators, which we might want to update in order to allow a different iteration order. But I think it'll make better sense in that case to do what I just did, and check the priority objfile first, and then call the iterator. Following that thread, one can see that the callers of "lookup_symtab" might want to ask that a particular objfile be checked first. But in the end, I decided to stop looking, because the call tree quickly explodes... -- Joel