From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67337 invoked by alias); 16 Jul 2019 03:28:09 -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 67329 invoked by uid 89); 16 Jul 2019 03:28:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:sk:server-, pm, UD:p.m, faced X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Jul 2019 03:28:06 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 897C11E092; Mon, 15 Jul 2019 23:28:04 -0400 (EDT) Subject: Re: [PATCH][PR/24474] Make gdb.lookup_static_symbol also check the STATIC_SCOPE To: Christian Biesinger , gdb-patches@sourceware.org References: <20190605012421.252953-1-cbiesinger@google.com> From: Simon Marchi Message-ID: <8f4bcc74-18a0-c8f6-b97d-aef05021a656@simark.ca> Date: Tue, 16 Jul 2019 03:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190605012421.252953-1-cbiesinger@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-07/txt/msg00372.txt.bz2 On 2019-06-04 9:24 p.m., Christian Biesinger via gdb-patches wrote: > gdb/ChangeLog: > > 2019-06-04 Christian Biesinger > > PR/24474: Make gdb.lookup_global_symbol also check the STATIC_SCOPE > because from a C/C++ developer's perspective, these are also globals. > * NEWS: Mention this change. > * python/py-symbol.c (gdbpy_lookup_global_symbol): Call > lookup_static_symbol if lookup_global_symbol returns NULL. > > gdb/testsuite/ChangeLog: > > 2019-06-04 Christian Biesinger > > * gdb.python/py-symbol.c: Add a static variable and one in an anonymous > namespace. > * gdb.python/py-symbol.exp: Check that lookup_global_symbol finds those > variables. Hi Christian, Sorry for the delay, I'll try to help you with this. I am not sure this is the right thing to do, or at least some things need to be clarified. Global symbols are visible through the entire program (there can only be one of that name), whereas there can be many static symbols with the same name. What should the user expect if there are multiple static symbols with the same name? I suppose we'll return the first one that matches, without any particular guarantee about which one. It is possible to get to a particular static symbol using gdb.lookup_symbol, provided you pass a block that is under the right static block, and that no other symbol shadows this one from the point of view of the block. But IIRC, it can prove difficult to get access the static block of a particular compilation unit (if you don't yet have a reference to a frame block under that static block). I have been thinking for a while that we are missing the concept of compilation units in our Python API, that would be the bridge between objfiles and global/static blocks. - From an objfile, you could list all included compilation units or search through them - From the compilation unit, you could obtain its global/static block. >From there, you could use gdb.lookup_symbol, passing the static block of the compilation unit. However, in my (naive) attempt at adding compunits to the Python API [1], which consisted of wrapping compunit_symtab objects in Python, the problem I faced is that compunit_symtab objects are not created until full symbols are read. So unless you used -readnow, you would not see all the compilation units you would expect (because they are lazily created). Would it be an option to add a gdb.lookup_static_symbol function, that would only look through the static blocks? Its behavior could be that if you don't pass a block, it searches through all the static blocks until it finds a matching symbol (just like your patch does with gdb.lookup_global_symbol if no symbol is found). And if you pass a block, it restricts the search to the static block linked to that block, ensuring you find the static symbol you want. Simon [1] https://github.com/simark/binutils-gdb/commits/py-compunit