From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id zLZ5MpN582muewYAWB0awg (envelope-from ) for ; Thu, 30 Apr 2026 11:47:31 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=oTrG4cLo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BB8081E0BA; Thu, 30 Apr 2026 11:47:31 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 8C2D31E067 for ; Thu, 30 Apr 2026 11:47:30 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 1C079436A04F for ; Thu, 30 Apr 2026 15:47:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1C079436A04F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1777564049; bh=tzWD3HH7gBV49wwnekvoUcK2S7ClK3SL8DLCBOGK3Po=; h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=oTrG4cLo2WBpIvqVSCLXEn9Or2NFegzkW4jKkbba2VU5gOFXNB6ezNVqgpq2LIOVc mdYYA+waRtz+0jeHBBCqbpy5sB9sPJHgLI58uSd4evM5ObfWWX0VkeR7jgC0rsozcC 2UsfPAYciyh1rNEbULl8yvHF3dJ4r7P2KHau7gWA= Received: from mail-4317.protonmail.ch (mail-4317.protonmail.ch [185.70.43.17]) by sourceware.org (Postfix) with ESMTPS id C86254BB24E1 for ; Thu, 30 Apr 2026 15:46:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C86254BB24E1 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C86254BB24E1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777564015; cv=none; b=K0ZGS5yWJc932sVkyIn5c/+nbX/pCMz2KxkcbXeg0bSe/M8OYPCewqelGkw2Wy6alsz+wjxzlENDVj2rUqFiFLyGVmfu21OmuM1A6jiyqVAoYEymmJRpgS8qXnmzw9/sXy6uVMkPLEUR8WDjlZcqK8y9FQF2/QcY+pdgffHTNy0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777564015; c=relaxed/simple; bh=z6xwxmvsWhDEn7tKhmPcvOSpK8BzmpgZapf6n3Hsk2s=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=XRZmvFR7l7EjBgFbh1LYLMgGL7ouwv0NLj5yrLCPbrodVi3kCeWYcFnmB6nubA8T3STdNo1jhxOPn1eA3ERxCm60odgf4utiRDnm5bgx7Ckr29uasfysFXqxmrWBK/3ygPDDHPjVb7zUoDt0EU/tRHpM+lcBC1RovgXhbw380dk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C86254BB24E1 Date: Thu, 30 Apr 2026 15:46:47 +0000 To: Guinevere Larsen Cc: "gdb@sourceware.org" Subject: Re: Question about adding a new option vs extending an existing one Message-ID: <-tT8gWCj1g1GjvJRl43XWZw617t_INK4DMPtVHfOvkCNNIFLeYs2Fylz6xQLXmVXqo69m-h3iMq4yFB9WDuZCrQKeVqtRDlOGO1lAbt9AXc=@zanderwork.com> In-Reply-To: <3ff2c828-eb48-4c5a-9862-5fc6e9be3231@redhat.com> References: <3ff2c828-eb48-4c5a-9862-5fc6e9be3231@redhat.com> Feedback-ID: 10509189:user:proton X-Pm-Message-ID: b7461d8f3ae9b160a74d30cd16fa570c049cbfe2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Zander Work via Gdb Reply-To: Zander Work Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Cool, that makes sense! Patch (hopefully) coming soon for this. -Zander On Wednesday, April 29th, 2026 at 10:40 AM, Guinevere Larsen wrote: > On 4/29/26 9:45 AM, Zander Work via Gdb wrote: > > Hello, > > > > I'm interested in writing a patch for GDB which allows a user to change= the radix used for displaying function offsets in instruction listings (ex= ample below), right now it only uses decimal, and doesn't respect the exist= ing radix settings (either `radix` or `output-radix`). > > > > I want to contribute a patch that allows the user to change the radix u= sed for displaying these offsets, but I'm not sure if it would be best to r= e-use the value of `output-radix`, or to define a new setting (eg, `offset-= radix` maybe). > > > > Additionally, if a new option should be added, would it be appropriate = to have `set radix` also set that new one (I would assume yes). > > > > Does anyone have any opinions on this? My personal feeling is that reus= ing `output-radix` would be best. >=20 > In this case, based on how "set radix" is described in the manual, I > think this is actually a bug and the offset should already be using the > specified (output-)radix, so I guess I am with you on the opinion, but > from the POV that it should already be happening and you're fixing a > bug, not that it is a feature being extended >=20 > -- > Cheers, > Guinevere Larsen > It/she >=20 > > > > --- > > > > (gdb) set radix 16 > > Input and output radices now set to decimal 16, hex 10, octal 20. > > (gdb) x/8i $rip > > =3D> 0x7ffff7fe0c00 <_start>: mov %rsp,%rdi > > 0x7ffff7fe0c03 <_start+3>: call 0x7ffff7fe1750 <_dl_start> > > 0x7ffff7fe0c08 <_dl_start_user>: mov %rax,%r12 > > 0x7ffff7fe0c0b <_dl_start_user+3>: mov %rsp,%r13 > > 0x7ffff7fe0c0e <_dl_start_user+6>: mov 0x1cb9c(%rip),%edx = # 0x7ffff7ffd7b0 <_rtld_global+1968> > > 0x7ffff7fe0c14 <_dl_start_user+12>: test $0x2,%edx > > 0x7ffff7fe0c1a <_dl_start_user+18>: je 0x7ffff7fe0c2d <_dl_sta= rt_user+37> > > 0x7ffff7fe0c1c <_dl_start_user+20>: mov $0x1,%esi > > ^^ i am referring to these offsets > > > > >=20 >