From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94720 invoked by alias); 11 Nov 2019 16:27:36 -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 94663 invoked by uid 89); 11 Nov 2019 16:27:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=crazy, symtabc, objfile, UD:symtab.c X-HELO: mail-wm1-f67.google.com Received: from mail-wm1-f67.google.com (HELO mail-wm1-f67.google.com) (209.85.128.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Nov 2019 16:27:34 +0000 Received: by mail-wm1-f67.google.com with SMTP id u18so6362640wmc.3 for ; Mon, 11 Nov 2019 08:27:33 -0800 (PST) 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=OBx9hKQr4GpOYwqfpct5vmp17+kbqwIEJcttQ5v1hMM=; b=gxprLRRV+Pw3VZ3GI9OFotKhlDfW6HVjdHZTkrVLzTocl9Yc4323hFVBMj9BdoKyHC IHzTV+OxNohVJ+QDlQUvGAobOuFPbw6yzSJIpTqFRfIqe9X9AFQkn+ujoV1DlxQOFkvz 8m7ncfhIfEqsCHi6bYOSTrcJQUdR0zQe/RrbdrHlLOUf2jSRsJJu7z86PLTin/BerXV2 inK341Yv4ZT8nhmaQ61FLv85No2IYqPLgi+hvei5ADqjvC2z9v4FbVyRbtledxUpbEaM pBZHCIPebVkVnle06d77OhB3NNiwkzOTQEnP4cZNV3li7DvrfMLCkAkt5gBCQd+KKa7P VfHA== Return-Path: Received: from localhost (host86-128-12-122.range86-128.btcentralplus.com. [86.128.12.122]) by smtp.gmail.com with ESMTPSA id 19sm34929096wrc.47.2019.11.11.08.27.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Nov 2019 08:27:31 -0800 (PST) Date: Mon, 11 Nov 2019 16:27:00 -0000 From: Andrew Burgess To: Christian Biesinger Cc: Simon Marchi , gdb-patches Subject: Re: [PATCH] gdb/python: Introduce gdb.lookup_all_static_symbols Message-ID: <20191111162730.GJ11037@embecosm.com> References: <20191023191354.GH4962@embecosm.com> <20191101115304.GR4962@embecosm.com> <20191104171204.GB11037@embecosm.com> <20093265-f125-8668-d7ba-0c36b07a53ec@simark.ca> <20191110222731.GH11037@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: Your boyfriend takes chocolate from strangers. 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-11/txt/msg00288.txt.bz2 * Christian Biesinger [2019-11-10 16:36:52 -0600]: > On Sun, Nov 10, 2019 at 4:27 PM Andrew Burgess > wrote: > > > > * Christian Biesinger [2019-11-09 00:23:00 -0600]: > > > > > On Mon, Nov 4, 2019 at 12:28 PM Simon Marchi wrote: > > > > > > > > On 2019-11-04 12:12 p.m., Andrew Burgess wrote: > > > > > How about I merged patches #1 and #2, but drop #3 for now? This would > > > > > give: > > > > > > > > > > lookup_static_symbol - returns the global static symbol for the > > > > > current compilation unit, or whatever else GDB can find if > > > > > there's nothing in the current CU. This is basically inline > > > > > with what we get from 'print symbol_name' at the CLI (if we > > > > > limit symbol_name to just global static things). > > > > > > > > > > AND, > > > > > > > > > > lookup_static_symbols - returns the list of all global static > > > > > symbols. > > > > > > > > > > We no longer have a block parameter passed to 'lookup_static_symbol', > > > > > so hopefully and confusion can be avoided. If/when we later add a > > > > > Python wrapper for CU we can _extend_ the API for lookup_static_symbol > > > > > to also take a CU and so provide the "look over there" type behaviour > > > > > in a clearer way. > > > > > > > > > > Would everyone be happy with this? > > > > > > > > I certainly would, I think that brings us back to the same place we were before > > > > it was suggested to add the block parameter, doesn't it? > > > > > > Sorry for the late reply & for confusing things -- yes, after reading > > > through all the discussions I think that's the best way forward. > > > > Thanks for the feedback. > > > > I've now pushed patches #1 and #2. > > Thanks! By the way, should Objfile also get a lookup_static_symbols > method now, similar to Objfile.lookup_static_symbol? > > (I don't personally have a use-case for this, but figured I should > ask) I don't think that's a crazy idea, but I don't plan to write one right now. My interest in this area started when I was auditing how the GDB function lookup_static_function (the one in symtab.c) was used, and I felt that the way it was used in the python code wasn't quite right. I don't have any specific use cases to address. We can always add extra API methods later if/when there's a need for them without breaking backward compatibility, so I'm happy to leave this for now. Thanks, Andrew