From patchwork Mon Oct 27 04:50:18 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Evans X-Patchwork-Id: 3397 Received: (qmail 3926 invoked by alias); 27 Oct 2014 04:51:10 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 3912 invoked by uid 89); 27 Oct 2014 04:51:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f178.google.com Received: from mail-pd0-f178.google.com (HELO mail-pd0-f178.google.com) (209.85.192.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 27 Oct 2014 04:51:07 +0000 Received: by mail-pd0-f178.google.com with SMTP id fp1so1637101pdb.37 for ; Sun, 26 Oct 2014 21:51:06 -0700 (PDT) X-Received: by 10.70.89.132 with SMTP id bo4mr21741799pdb.25.1414385466131; Sun, 26 Oct 2014 21:51:06 -0700 (PDT) Received: from seba.sebabeach.org.gmail.com (173-13-178-50-sfba.hfc.comcastbusiness.net. [173.13.178.50]) by mx.google.com with ESMTPSA id ky4sm9573224pbc.55.2014.10.26.21.51.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Oct 2014 21:51:05 -0700 (PDT) From: Doug Evans To: gdb-patches@sourceware.org Subject: [PATCH 6/9] symtab.c (basic_lookup_symbol_nonlocal): Add comment. Date: Sun, 26 Oct 2014 21:50:18 -0700 Message-ID: MIME-Version: 1.0 X-IsSubscribed: yes Hi. This patch just adds a comment. The topic here is whether, when searching all objfiles for global syms, to first search the "current" objfile (the objfile of the BLOCK parameter), or to just search all objfiles starting from the beginning. There is actually a gdbarch API routine for this: gdbarch_iterate_over_objfiles_in_search_order The default is to not do anything special. Windows has its own version in windows-tdep.c for this reason: On Windows, the system behaves a little differently when two objfiles each define a global symbol using the same name, compared to other platforms such as GNU/Linux for instance. On GNU/Linux, all instances of the symbol effectively get merged into a single one, but on Windows, they remain distinct. As a result, it usually makes sense to start global symbol searches with the current objfile before expanding it to all other objfiles. This helps for instance when a user debugs some code in a DLL that refers to a global variable defined inside that DLL. When trying to print the value of that global variable, it would be unhelpful to print the value of another global variable defined with the same name, but in a different DLL. The performance cost here can be significant with several libraries (100s or 1000s). Plus as a user searching the current objfile is the intuitively obvious thing to do (to me anyway), regardless of whether the system has any rules as to whether it matters what the search order is. Thus I think we could always just use the windows search order, and this gdbarch API routine can go away, but that's another patch for another day. 2014-10-26 Doug Evans * symtab.c (basic_lookup_symbol_nonlocal): Add comment. diff --git a/gdb/symtab.c b/gdb/symtab.c index 17f7499..07e9fce 100644 --- a/gdb/symtab.c +++ b/gdb/symtab.c @@ -1789,6 +1789,10 @@ basic_lookup_symbol_nonlocal (const char *name, than that one, so I don't think we should worry about that for now. */ + /* NOTE: dje/2014-10-26: The lookup in all objfiles search could skip + the current objfile. Searching the current objfile first is useful + for both matching user expectations as well as performance. */ + sym = lookup_symbol_in_static_block (name, block, domain); if (sym != NULL) return sym;