From patchwork Fri Sep 20 19:20:11 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom Tromey X-Patchwork-Id: 34618 Received: (qmail 117301 invoked by alias); 20 Sep 2019 19:20:23 -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 117268 invoked by uid 89); 20 Sep 2019 19:20:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-21.5 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=FULL, HX-Languages-Length:3650 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Sep 2019 19:20:22 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id F21BF5607A; Fri, 20 Sep 2019 15:20:19 -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 jaXBBMuKpYPT; Fri, 20 Sep 2019 15:20:19 -0400 (EDT) Received: from murgatroyd.Home (71-218-73-27.hlrn.qwest.net [71.218.73.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPSA id 9D26B56075; Fri, 20 Sep 2019 15:20:19 -0400 (EDT) From: Tom Tromey To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH v2 2/8] Search global block from basic_lookup_symbol_nonlocal Date: Fri, 20 Sep 2019 13:20:11 -0600 Message-Id: <20190920192017.15293-3-tromey@adacore.com> In-Reply-To: <20190920192017.15293-1-tromey@adacore.com> References: <20190920192017.15293-1-tromey@adacore.com> MIME-Version: 1.0 From: Andrew Burgess This changes lookup_global_symbol to look in the global block of the passed-in block. If no block was passed in, it reverts to the previous behavior. This change is needed to ensure that 'FILENAME'::NAME lookups work properly. As debugging Pedro's test case showed, this was not working properly in the case where multiple identical names could be found (the one situation where this feature is truly needed :-). This also removes some old comments from basic_lookup_symbol_nonlocal that no longer apply. Note that the new test cases for this change will appear in a later patch. They are in gdb.base/print-file-var.exp. gdb/ChangeLog 2019-08-27 Andrew Burgess * symtab.c (lookup_global_symbol): Search global block. --- gdb/ChangeLog | 4 ++++ gdb/symtab.c | 41 +++++++++++++---------------------------- 2 files changed, 17 insertions(+), 28 deletions(-) diff --git a/gdb/symtab.c b/gdb/symtab.c index 35eab08cb37..0d29e243b9e 100644 --- a/gdb/symtab.c +++ b/gdb/symtab.c @@ -2414,34 +2414,6 @@ basic_lookup_symbol_nonlocal (const struct language_defn *langdef, { struct block_symbol result; - /* NOTE: carlton/2003-05-19: The comments below were written when - this (or what turned into this) was part of lookup_symbol_aux; - I'm much less worried about these questions now, since these - decisions have turned out well, but I leave these comments here - for posterity. */ - - /* NOTE: carlton/2002-12-05: There is a question as to whether or - not it would be appropriate to search the current global block - here as well. (That's what this code used to do before the - is_a_field_of_this check was moved up.) On the one hand, it's - redundant with the lookup in all objfiles search that happens - next. On the other hand, if decode_line_1 is passed an argument - like filename:var, then the user presumably wants 'var' to be - searched for in filename. On the third hand, there shouldn't be - multiple global variables all of which are named 'var', and it's - not like decode_line_1 has ever restricted its search to only - global variables in a single filename. All in all, only - searching the static block here seems best: it's correct and it's - cleanest. */ - - /* NOTE: carlton/2002-12-05: There's also a possible performance - issue here: if you usually search for global symbols in the - current file, then it would be slightly better to search the - current global block before searching all the symtabs. But there - are other factors that have a much greater effect on performance - 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. */ @@ -2674,6 +2646,19 @@ lookup_global_symbol (const char *name, const struct block *block, const domain_enum domain) { + /* If a block was passed in, we want to search the corresponding + global block first. This yields "more expected" behavior, and is + needed to support 'FILENAME'::VARIABLE lookups. */ + const struct block *global_block = block_global_block (block); + if (global_block != nullptr) + { + symbol *sym = lookup_symbol_in_block (name, + symbol_name_match_type::FULL, + global_block, domain); + if (sym != nullptr) + return { sym, global_block }; + } + struct objfile *objfile = lookup_objfile_from_block (block); return lookup_global_or_static_symbol (name, GLOBAL_BLOCK, objfile, domain); }