From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2013 invoked by alias); 28 Oct 2014 03:16:16 -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 2003 invoked by uid 89); 28 Oct 2014 03:16:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Oct 2014 03:16:13 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1XixGU-0004Bz-Ef from Yao_Qi@mentor.com ; Mon, 27 Oct 2014 20:16:10 -0700 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.181.6; Mon, 27 Oct 2014 20:16:09 -0700 From: Yao Qi To: Doug Evans CC: Subject: Re: [PATCH 7/9] Rewrite lookup_static_symbol to use gdbarch routine References: Date: Tue, 28 Oct 2014 03:16:00 -0000 In-Reply-To: (Doug Evans's message of "Sun, 26 Oct 2014 22:00:22 -0700") Message-ID: <87d29cvqfu.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00750.txt.bz2 Doug Evans writes: > struct symbol * > lookup_static_symbol_aux (const char *name, const domain_enum domain) > { > struct objfile *objfile; > struct symbol *sym; > > sym =3D lookup_symbol_aux_symtabs (STATIC_BLOCK, name, domain); > if (sym !=3D NULL) > return sym; > > ALL_OBJFILES (objfile) > { > sym =3D lookup_symbol_aux_quick (objfile, STATIC_BLOCK, name, domain); > if (sym !=3D NULL) > return sym; > } > > return NULL; > } > > Note what we're doing here. > First we're searching over all expanded symtabs in all objfiles, > and then we search partial/gdb_index tables in all objfiles. Eh? > > Normally when looking up a symbol in a particular objfile > we first list in expanded symtabs and then look in partial/gdb_index > tables. And *then* we try the next objfile. > > I can't think of any justification for the current behaviour. > > This patch changes things to be consistent, > but it is a behavioural change. Yes, it changes the behavior. Here is an example in my mind, but not sure it is correct or not, say, we have a static int foo defined in two objfiles respectively (1.c and 2.c), foo is in the partial table of two objfiles, but is only expanded to the full symtab of *one* objfile (2.c). 1.c 2.c partial foo foo full foo before your patch, GDB gets foo from 2.c full table, and after it, GDB gets foo from 1.c partial table. Is it possible? Regarding the change, we also need to update the comments to iterate_over_objfiles_in_search_order in gdbarch.sh, # Iterate over all objfiles in the order that makes the most sense # for the architecture to make global symbol searches. ^^^^^^^^^^^^^ > The testsuite passes, and any noticeable difference > by this change would be dependent on the order in which > symtabs got expanded. Thus I can't think of a reason to not > apply this change. If read this correctly, Joel expressed the same intention there. Since gdbarch method iterate_over_objfiles_in_search_order was added for windows target and this patch uses it, we need to test it on windows target. If you don't have mingw testing env, let me know, I'll see if I can do the test. --=20 Yao (=E9=BD=90=E5=B0=A7)