From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id VGnNBcIuImJGBgAAWB0awg (envelope-from ) for ; Fri, 04 Mar 2022 10:22:42 -0500 Received: by simark.ca (Postfix, from userid 112) id 07D371F3CA; Fri, 4 Mar 2022 10:22:42 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 825441EA69 for ; Fri, 4 Mar 2022 10:22:41 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2F0C43857C49 for ; Fri, 4 Mar 2022 15:22:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F0C43857C49 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1646407361; bh=b1/c68DSHgCLkv5JHvspTEyRjuDHLBttbqveQWrZPxE=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=juV4hHX6c7zW/0Qsd0G4vKsu2vlf1n6m10uvrzpnbh7s5mNZA5JNPVsfyQrXz1uX1 arOnA04KBSw+XYJfj+TkmQgnOjiNDHxhIq5n28WMMd3ZJkpYD3ybQyymYgjLWZ9z8H eFlxXkPKpCLMY6xi2T/8Rrakb0leNHA+0Yq6evJ4= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id BBD6D3858D39 for ; Fri, 4 Mar 2022 15:22:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BBD6D3858D39 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 224FM4HD031835 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Mar 2022 10:22:09 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 224FM4HD031835 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id EE9331EA69; Fri, 4 Mar 2022 10:22:03 -0500 (EST) Message-ID: <286a1f88-1e4e-b2f1-1503-d8ddbb420452@polymtl.ca> Date: Fri, 4 Mar 2022 10:22:03 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCHv2] gdb/python: add gdb.Architecture.format_address Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <20220211161721.3252422-1-aburgess@redhat.com> <20220304105031.2706582-1-aburgess@redhat.com> In-Reply-To: <20220304105031.2706582-1-aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 4 Mar 2022 15:22:04 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: Andrew Burgess Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > @@ -391,6 +416,12 @@ group GROUP-NAME." }, > METH_NOARGS, > "register_groups () -> Iterator.\n\ > Return an iterator over all of the register groups in this architecture." }, > + { "format_address", (PyCFunction) archpy_format_address, > + METH_VARARGS | METH_KEYWORDS, > + "format_address (ADDRESS) -> String.\n\ > +Format ADDRESS, an address within the currently selected inferior's\n\ > +address space, as a string. The format of the returned string is\n\ I didn't have much time to think about this, but I was just wondering if there would be a way to avoid relying on the currently selected inferior. My understanding is that this function depends on both an architecture, for formatting the number part of the address, and an inferior for the symbolic part of the the address. Or is it a program space instead of inferior? So the possibilities I see are, to let the user specify both: arch_obj.format_address(addr, inf_obj) arch_obj.format_address(addr, pspace_obj) inf_obj.format_address(addr, arch_obj) pspace_obj.format_address(addr, arch_obj) gdb.format_address(addr, inf_obj, arch_obj) gdb.format_address(addr, pspace_obj, arch_obj) Putting the format_address on one of the objects (arch, inf, pspace) seems strange, because it's not a arch-specific operation more than it is an inf-specific (or pspace-specific operation). So I'm more leaning towards gdb.format_address. And even if the user can pass in objects, we can offer sensible defaults that will make format_address use "the current things". Let's say that format_address is declared as: def format_address(addr, pspace_obj=None, arch_obj=None) If pspace_obj is None, we can fetch it from the currently selected inferior. And same for arch_obj. Also, maybe that doing: format_address(addr, inf_obj) could be a shortcut for: format_address(addr, inf_obj.progspace, inf_obj.architecture()) Not sure about that one though. Simon