From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org 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-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: * 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: Mon, 21 Feb 2022 18:02:22 -0000 > 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.