From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126200 invoked by alias); 21 Sep 2019 04:32:12 -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 126186 invoked by uid 89); 21 Sep 2019 04:32:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-18.3 required=5.0 tests=AWL,BAYES_00,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham version=3.3.1 spammy=HX-Languages-Length:997 X-HELO: mail-oi1-f196.google.com Received: from mail-oi1-f196.google.com (HELO mail-oi1-f196.google.com) (209.85.167.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 21 Sep 2019 04:32:10 +0000 Received: by mail-oi1-f196.google.com with SMTP id w144so3517152oia.6 for ; Fri, 20 Sep 2019 21:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lKv8R4Dn8QORuIGvTex42R+XCnuGDHMLEMrnRzy3xRg=; b=OMd/iBcWRbkWe9LtlWWhz4aLrA/Y73L4RCrSX14V0xHQw+Wrjamx8koRocwnvVdhNU iRf/Pzk3uiWfuOra1Xa/zEKGEFnCOb+aCtPWDj8PZli96ODhijo19PWdpDqYpmzZyY1v mj4MU/S7RzAjjqwfX/wb2mvJW6mZPxjgHzN6h6l/tNOdiwuuxi/y2xK7MSFD7CMDTRx0 dnJi9nXD+xJpUSKNmBZtZJBStHP7t4ZEjhOHbeh8mzkPjQb3Jp6SvY3O2TEpm52QFJ/p q9qRYGUNnltACwFEGlAmO8PTUb+gTP2IUwN3NloMZkh3zXNvsI1J31FZS/qRdOpYX2yt 8Crw== MIME-Version: 1.0 References: <20190920192017.15293-1-tromey@adacore.com> <20190920192017.15293-3-tromey@adacore.com> In-Reply-To: <20190920192017.15293-3-tromey@adacore.com> From: "Christian Biesinger via gdb-patches" Reply-To: Christian Biesinger Date: Sat, 21 Sep 2019 04:32:00 -0000 Message-ID: Subject: Re: [PATCH v2 2/8] Search global block from basic_lookup_symbol_nonlocal To: Tom Tromey Cc: gdb-patches , Andrew Burgess Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00432.txt.bz2 On Sat, Sep 21, 2019 at 4:20 AM Tom Tromey wrote: > 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 further extends the situations where lookup_global_symbols checks a local scope first (currently only objfile) but lookup_static_symbol doesn't. Is that really correct? I would think that lookup_static_symbol is even more likely to need that check, since static symbols are probably (?) more likely to share the same name. Is my interpretation wrong? Christian