From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-158475-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 88780 invoked by alias); 27 Aug 2019 18:17:18 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 88772 invoked by uid 89); 27 Aug 2019 18:17:18 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-18.1 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=
X-HELO: mail-ot1-f68.google.com
Received: from mail-ot1-f68.google.com (HELO mail-ot1-f68.google.com) (209.85.210.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Aug 2019 18:17:16 +0000
Received: by mail-ot1-f68.google.com with SMTP id 100so100450otn.2        for <gdb-patches@sourceware.org>; Tue, 27 Aug 2019 11:17:16 -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=iBhUmlipIhTDyLOoFLeKT6Pb0lCNsBmsj0p48xSEHK0=;        b=IniemruHNNM5UYb2dlCofG6DW45q+KZlIS/PigrqmYiunqY4EAe7vRWtlsQ+VGPRxo         0/AyKnm5HOknAzd/yCtMoFpiTZ2VvmXV3UsxHbeVO9L8z4t/36gGOqGJjH2PjBrKWp0Z         g8UdUqSnMtQWs4+sXfVXD7k7k1f06DJTtGnzmAsivwOF5cnt/woOULJBCu7A5A5gCvkE         M/mp7dzV2wxRVFAqVwCEYMjbQdUKQ2M9SsmWuynoKdkEKEN+qj2DqMgGOEoXK/Durirh         R+kOQ1ffJtj+5hUE2rPys4XoK4D/VEt4SxpgKDXpfp/TTA1G5A40XhmPPNZUaWbreKhZ         oIwQ==
MIME-Version: 1.0
References: <20190801170412.5553-1-tromey@adacore.com> <20190801170412.5553-5-tromey@adacore.com> <20190821103225.GF6076@embecosm.com> <20190827095357.GO6076@embecosm.com>
In-Reply-To: <20190827095357.GO6076@embecosm.com>
From: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
Reply-To: Christian Biesinger <cbiesinger@google.com>
Date: Tue, 27 Aug 2019 18:17:00 -0000
Message-ID: <CAPTJ0XF2shJX6PJOMd9se3rVWn1ZMr0Vcwi0KPSGH6e-idWiNg@mail.gmail.com>
Subject: Re: [PATCH v2 4/8] Search global block from basic_lookup_symbol_nonlocal
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: Tom Tromey <tromey@adacore.com>, gdb-patches <gdb-patches@sourceware.org>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2019-08/txt/msg00612.txt.bz2

On Tue, Aug 27, 2019 at 4:54 AM Andrew Burgess
<andrew.burgess@embecosm.com> wrote:
> @@ -2662,6 +2646,22 @@ lookup_global_symbol (const char *name,
>    if (objfile != NULL)
>      result = solib_global_lookup (objfile, name, 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)
> +    {
> +      result.symbol = lookup_symbol_in_block (name,
> +                                             symbol_name_match_type::FULL,
> +                                             global_block, domain);
> +      if (result.symbol != nullptr)
> +       {
> +         result.block = global_block;
> +         return result;
> +       }
> +    }
> +
>    /* If that didn't work go a global search (of global blocks, heh).  */
>    if (result.symbol == NULL)
>      {

I like this change but shouldn't this call happen before solib_global_lookup?

(That said, I would like to remove that function...
https://patches-gcc.linaro.org/patch/21673/)

Christian