From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Cc: Andrew Burgess References: <20220211161721.3252422-1-aburgess@redhat.com> <20220304105031.2706582-1-aburgess@redhat.com> From: Simon Marchi 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-Spam-Status: No, score=-3033.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 04 Mar 2022 15:22:23 -0000 > @@ -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