From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id HhHsMabUE2JtIgAAWB0awg (envelope-from ) for ; Mon, 21 Feb 2022 13:06:30 -0500 Received: by simark.ca (Postfix, from userid 112) id BC5311F3CB; Mon, 21 Feb 2022 13:06:30 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.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 26BA11F3C9 for ; Mon, 21 Feb 2022 13:06:30 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9CE81385E017 for ; Mon, 21 Feb 2022 18:06:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9CE81385E017 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1645466789; bh=ggF6O11lyUOyQkbLY91zfwI9nf4PcZqu0pID+ctGuSc=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=D3EWBpoJvfV2uaw3Cl/n8yjSXlHibd1ftnw4w88sodSp4tdqXp1odmYjXaWZEubNq Oq3aPLLs2PON5EEhqTavPfs46MLlZ0rFDZMfvPuw9l6ooj2RDT9/LaB1iR4HCIouWC lVw1CTMW22QKQqrMmuI3A5MG5Xwfj5n36WzsqNtI= Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id E4A163857824 for ; Mon, 21 Feb 2022 18:02:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E4A163857824 Received: from [2001:470:142:3::e] (port=58082 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMD0t-0005q0-Jm; Mon, 21 Feb 2022 13:02:20 -0500 Received: from [87.69.77.57] (port=4768 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMD0t-0000Po-03; Mon, 21 Feb 2022 13:02:19 -0500 Date: Mon, 21 Feb 2022 20:02:22 +0200 Message-Id: <837d9oumhd.fsf@gnu.org> To: Andrew Burgess In-Reply-To: <878ru4cepy.fsf@redhat.com> (message from Andrew Burgess on Mon, 21 Feb 2022 17:27:21 +0000) Subject: Re: [PATCH] gdb/python: add gdb.Architecture.format_address References: <20220211161721.3252422-1-aburgess@redhat.com> <83leyhs07f.fsf@gnu.org> <878ru4cepy.fsf@redhat.com> 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: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > From: Andrew Burgess > Cc: gdb-patches@sourceware.org > Date: Mon, 21 Feb 2022 17:27:21 +0000 > > I'm certainly not against renaming, if we can come up with a better > name... maybe 'format_address_info'? I don't know... I still kind of > like 'format_address'... I hope someone will come up with a better name. > +@defun Architecture.format_address (@var{address}) > +Return a string in the format @samp{ADDRESS }, where > +@samp{ADDRESS} is @var{address} formatted in hexadecimal, > +@samp{SYMBOL} is a symbol, the address range of which, covers > +@var{address}, and @samp{OFFSET} is the offset from @samp{SYMBOL} to > +@var{address} in decimal. This is the same format that @value{GDBN} > +uses when printing address, symbol, and offset information, for > +example, within disassembler output. > + > +If no @samp{SYMBOL} has an address range that covers @var{address}, > +then the @samp{} part is not included in the returned > +string, instead the returned string will just contain the > +@var{address} formatted as hexadecimal. > + > +In all cases, the @samp{ADDRESS} component will be padded with leading > +zeros based on the width of an address for the current architecture. This is okay, but needs the markup fixed. All the places where you use SOMETHING ("ADDRESS", "SYMBOL", etc.) should be @var{something}, i.e. have the @var markup and be in lower-case. (To prevent confusion with the argument @var{address}, call it something else, like @var{addr}.) Also, remove @samp everywhere except this single instance: @samp{@var{address} <@var{symbol}+@var{offset}>} And finally, this text: > @samp{SYMBOL} is a symbol, the address range of which, covers > +@var{address} is better worded as @var{symbol} is the symbol to which @var{addr} belongs Btw, is the above accurate? does GDB really guarantee that ADDR is p[art of SYMBOL's memory? or does it just find the closest symbol whose address is smaller than ADDR? Thanks.