From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42863 invoked by alias); 26 Aug 2019 18:28: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 42833 invoked by uid 89); 26 Aug 2019 18:28:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-20.5 required=5.0 tests=AWL,BAYES_00,ENV_AND_HDR_SPF_MATCH,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham version=3.3.1 spammy=D*ca, our X-HELO: mail-ot1-f66.google.com Received: from mail-ot1-f66.google.com (HELO mail-ot1-f66.google.com) (209.85.210.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Aug 2019 18:28:10 +0000 Received: by mail-ot1-f66.google.com with SMTP id b1so16139970otp.6 for ; Mon, 26 Aug 2019 11:28: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=ZdoCoF6KEiWYiAWViOHEAxe3Y+wdcWk283I21/0bkA4=; b=s/yPeLnk1ck4gyk8I+gkX0kkv4eNWMIMSE8+8h04axLOO5H9KD7YOzRQBsbBpIMFjl m1pEJ/HtZqL0AuIiST+aZgt9wzr51WXwMYMxeXD0pIxHWm376AtQhiPFPP5heqvhY+gs 7BJfEd4zom3kGjRxVd0J9feykB+yQzeQo8jOTKDZGZe3rzF3gma29F+hFZH5qcfZe+pO twAJdqJvbhxslRwG1MU0VVwhVPzjg02VrAaKN+d/5IS016WhCU7Lvh0uzMW/pqFHcpqR ZJ6vvLT/CxrAPDTWAJx7VBkxWIZwoDAMd8VazkqySsNj9d2S7/OYowJR9LuljaUKOObJ cAtg== MIME-Version: 1.0 References: <20190805153326.95512-1-cbiesinger@google.com> <45f47d3b-c9f5-5419-517f-31a4a4b5d046@simark.ca> In-Reply-To: <45f47d3b-c9f5-5419-517f-31a4a4b5d046@simark.ca> From: "Christian Biesinger via gdb-patches" Reply-To: Christian Biesinger Date: Mon, 26 Aug 2019 18:28:00 -0000 Message-ID: Subject: Re: [PATCH v2] Factor out the common code in lookup_{static,global}_symbol To: Simon Marchi Cc: gdb-patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00599.txt.bz2 On Sun, Aug 25, 2019 at 9:20 PM Simon Marchi wrote: > > On 2019-08-05 11:33 a.m., Christian Biesinger via gdb-patches wrote: > > @@ -2614,6 +2576,9 @@ struct global_sym_lookup_data > > /* The domain to use for our search. */ > > domain_enum domain; > > > > + /* The block index in which to search */ > > Period and two spaces: > > /* The block index in which to search. */ Done > > -struct block_symbol > > -lookup_global_symbol (const char *name, > > - const struct block *block, > > - const domain_enum domain) > > +static struct block_symbol > > +lookup_global_symbol_internal (const char *name, > > + enum block_enum block_index, > > + const struct block *block, > > + const domain_enum domain) > > I'd rename that to lookup_symbol_internal, since it's used both in lookup_global_symbol and > lookup_static_symbol. If you think it's too general (the function doesn't look up local symbols), > Maybe "lookup_global_or_static_symbol"? And global_sym_lookup_data should be renamed accordingly. > > And since BLOCK is only used for looking up an objfile in the global case, I would suggest > making this function accept the objfile instead of a block. Otherwise, it could be confused > as "lookup symbol in this block". Also, if some code already has the objfile handy, they can > pass it down, in which case we avoid the cost of lookup_objfile_from_block. Done > > +/* See symtab.h. */ > > + > > +struct block_symbol > > +lookup_static_symbol (const char *name, const domain_enum domain) > > +{ > > + /* TODO: Should static symbol lookup start with a block as well, so we can > > + prefer a static symbol in the current CU? */ > > + return lookup_global_symbol_internal (name, STATIC_BLOCK, nullptr, domain); > > I'd say that we can add another argument when the need comes, it's not a stable API. Removed