From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124035 invoked by alias); 24 Oct 2019 16:53: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 124024 invoked by uid 89); 24 Oct 2019 16:53:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=demonstrated, HX-Spam-Relays-External:209.85.221.66, H*RU:209.85.221.66 X-HELO: mail-wr1-f66.google.com Received: from mail-wr1-f66.google.com (HELO mail-wr1-f66.google.com) (209.85.221.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 Oct 2019 16:53:10 +0000 Received: by mail-wr1-f66.google.com with SMTP id o28so26869511wro.7 for ; Thu, 24 Oct 2019 09:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rI1xJ3ryXIQxe9T6CvuOtecBiBVxL9vzvE+An2+4OWc=; b=civ7tY3MciiDoO4sC8o1PYHSTdzHv+UglcOn2RVrYCZujQRCDNujsDtqKL+PSmaHaE UNQWDc1zEu3ClwJBIbQPIBq3EcefeTQaMfY2EKIzCj9X35pis8u1bQ2H8MG6dskDbByv PrGtS5Y3H8ClZK/0ffHYzkND69sKCjgFbpMuOFiKLhm+RdId43MFFz4C8f9giEWSsyx1 3pxPqAOC8tet5Ei14Fb1nCScqC1Z6GMX6FTeXutQWTRzWXW83snV+1t3mo5MitBDbr3R ZAuA0EhtXrReJUKrHZ2j9wB198gzM3VrlEWHgBP/SlBKHOolKIdq5Y/1VXq3Xr54aw4d zqwA== Return-Path: Received: from localhost (host86-128-12-122.range86-128.btcentralplus.com. [86.128.12.122]) by smtp.gmail.com with ESMTPSA id o4sm38984869wre.91.2019.10.24.09.53.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 24 Oct 2019 09:53:07 -0700 (PDT) Date: Thu, 24 Oct 2019 16:53:00 -0000 From: Andrew Burgess To: Simon Marchi Cc: Christian Biesinger , gdb-patches Subject: Re: [PATCH] gdb/python: Introduce gdb.lookup_all_static_symbols Message-ID: <20191024165306.GM4962@embecosm.com> References: <20191015141515.GW4962@embecosm.com> <20191015164647.1837-1-andrew.burgess@embecosm.com> <32eba92d-55a9-5694-cec5-80001d8ff1ae@simark.ca> <20191023191354.GH4962@embecosm.com> <4582382d-b58a-8fa8-9478-168de34e2a82@simark.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4582382d-b58a-8fa8-9478-168de34e2a82@simark.ca> X-Fortune: Does someone from PEORIA have a SHORTER ATTENTION span than me? X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00888.txt.bz2 * Simon Marchi [2019-10-23 23:11:30 -0400]: > On 2019-10-23 3:13 p.m., Andrew Burgess wrote: > >>> I see two use cases here: > >>> > >>> 1. I want to get all static symbols named `foo`. In which case, I'd use the > >>> function Andrew proposes in this patch. > >>> 2. I want to get the static symbol named `foo` that's visible from a certain > >>> point, perhaps a given block or where my program is currently stopped at. > >>> Ideally, we would have a "CompilationUnit" object type in Python, such that > >>> I could use > >>> > >>> block.compunit.lookup_static_symbol('foo') > >>> > >>> or > >>> > >>> gdb.current_compunit().lookup_static_symbol('foo') > >> So technically, those don't give you "the static symbol named `foo` > >> that's visible from [this] point", because there could be static > >> variable in the function. > >> > >> Since we already have block objects, should this new function > >> optionally take a block to start the lookup in? > > When you say "new function", I assume you mean > > 'gdb.lookup_static_symbol' not 'gdb.lookup_static_symbols', as the > > second one always returns all symbols. > > > > Anyway, I took a stab at adding a block parameter to the first of > > these functions - is this what you were thinking? > > > > Thanks, > > Andrew > > I'm confused, I don't gdb.lookup_static_symbol(s) only look through > static symbols, as in file-level static variables? So, before patch 3 the situation was: gdb.lookup_static_symbol Return the file level static symbol matching a given name. Will return the static from the current file first, before searching through all other files. This matches the CLI behaviour for if you just typed: 'print var_name' (with var_name being file-level static). gdb.lookup_static_symbols Returns all of the file level static symbols matching a given name, the order corresponds to the order of the compilation units as found by GDB (I guess). In general a user shouldn't read any meaning into the order, just that these are all file level statics with that name. The last patch in the series modifies the first of these to take an optional block parameter. GDB will then find the file level static that would be seen from that block. This allows the user to ask the question, what file-level static would I see from over there, without actually having to be "over there". This is demonstrated in the testsuite changes where I lookup a block based on a $pc from some other function in a different file, I can then query the file-level static that would be visible from that function. Is this super useful? I don't know, I think this is what Christian was suggesting and adding the feature was both easy to implement and easy to test, so I figured why not. Thanks, Andrew