From: Zander Work <zdw@google.com>
To: Guinevere Larsen <guinevere@redhat.com>
Cc: gdb-patches@sourceware.org, Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH] Use "output-radix" setting to format function offsets
Date: Fri, 8 May 2026 15:59:19 -0700 [thread overview]
Message-ID: <CAB3ousCKmytOaWJMNC4kBm8oBqmUWOywg_bEnTutmm9M6vty_Q@mail.gmail.com> (raw)
In-Reply-To: <b8ebfd8a-d08d-4ca2-9f84-28abbc427037@redhat.com>
Thank you for the review! Replies inline, I will follow up (probably
next week) with a v2 of this patch.
-Zander
On Fri, May 8, 2026 at 6:45 AM Guinevere Larsen <guinevere@redhat.com> wrote:
>
> On 5/4/26 6:37 PM, Zander Work wrote:
> > This is a patch for a discussion [1] I had previously where it was
> > determined that it was a bug for GDB to not use the "output-radix"
> > setting for function offsets.
> >
> > This patch includes updates to the radix.exp tests, and I verified that
> > there were no new breakages added when running the full gdb testsuite
> > with this patch.
> >
> > I didn't make any changes to NEWS or a /gdb/ Changelog entry for this,
> > if I should please let me know.
>
> Hi! Thank you for working on this!
>
> Changelog entries are definitely no longer required, and I don't think
> this would need a NEWS entry either.
>
> I have some minor comments, mostly about styling or wondering about a
> few choices, but in general I think this patch is in the right direction!
>
> >
> > I also have not personally completed a FSF copyright assignment form.
> Yeah, for a patch this size, it will definitely be necessary. I'm adding
> Tom Tromey in CC since I know he knows about the assignment process
> (more than me, at least)
> >
> > Sample output with this patch:
> >
> > ```
> > (gdb) disas main
> > Dump of assembler code for function main:
> > 0x0000000000001149 <+0>: endbr64
> > 0x000000000000114d <+4>: push %rbp
> > 0x000000000000114e <+5>: mov %rsp,%rbp
> > 0x0000000000001151 <+8>: lea 0xeac(%rip),%rax # 0x2004
> > 0x0000000000001158 <+15>: mov %rax,%rdi
> > 0x000000000000115b <+18>: mov $0x0,%eax
> > 0x0000000000001160 <+23>: call 0x1050 <printf@plt>
> > 0x0000000000001165 <+28>: mov $0x0,%eax
> > 0x000000000000116a <+33>: pop %rbp
> > 0x000000000000116b <+34>: ret
> > End of assembler dump.
> > (gdb) set radix 0x10
> > Input and output radices now set to decimal 16, hex 10, octal 20.
> > (gdb) disas main
> > Dump of assembler code for function main:
> > 0x0000000000001149 <+0x0>: endbr64
> > 0x000000000000114d <+0x4>: push %rbp
> > 0x000000000000114e <+0x5>: mov %rsp,%rbp
> > 0x0000000000001151 <+0x8>: lea 0xeac(%rip),%rax # 0x2004
> > 0x0000000000001158 <+0xf>: mov %rax,%rdi
> > 0x000000000000115b <+0x12>: mov $0x0,%eax
> > 0x0000000000001160 <+0x17>: call 0x1050 <printf@plt>
> > 0x0000000000001165 <+0x1c>: mov $0x0,%eax
> > 0x000000000000116a <+0x21>: pop %rbp
> > 0x000000000000116b <+0x22>: ret
> > End of assembler dump.
> > ```
> >
> > [1] https://sourceware.org/pipermail/gdb/2026-April/052170.html
> > ---
> > gdb/disasm.c | 18 +++++++++++++----
> > gdb/printcmd.c | 2 +-
> > gdb/testsuite/gdb.base/radix.c | 31 +++++++++++++++++++++++++++++
> > gdb/testsuite/gdb.base/radix.exp | 34 ++++++++++++++++++++++++++++++++
> > gdb/valprint.c | 10 ++++++++++
> > gdb/valprint.h | 6 ++++++
> > 6 files changed, 96 insertions(+), 5 deletions(-)
> > create mode 100644 gdb/testsuite/gdb.base/radix.c
> >
> > diff --git a/gdb/disasm.c b/gdb/disasm.c
> > index 81c466c188a..5d19dea72b6 100644
> > --- a/gdb/disasm.c
> > +++ b/gdb/disasm.c
> > @@ -375,10 +375,20 @@ gdb_pretty_print_disassembler::pretty_print_insn (const struct disasm_insn *insn
> > m_uiout->field_string ("func-name", name,
> > function_name_style.style ());
> > /* For negative offsets, avoid displaying them as +-N; the sign of
> > - the offset takes the place of the "+" here. */
> > - if (offset >= 0)
> > - m_uiout->text ("+");
> > - m_uiout->field_signed ("offset", offset);
> > + the offset takes the place of the "+" here. For MI consumers,
> > + emit the integer value; otherwise, print the formatted offset based
> > + on the current 'output-radix'. */
> > + if (m_uiout->is_mi_like_p ())
> > + {
> > + if (offset >= 0)
> > + m_uiout->text ("+");
> > + m_uiout->field_signed ("offset", offset);
>
> I'm not familiar with the radix functionality, so this is a genuine
> quesiton, but shouldn't the MI interface also honor the radix request?
>
> It seems to me like it would make sense, but if other MI messages don't,
> your approach here seems right.
My assumption was that a change from an int-type to a string-type may
cause compatibility/API contract
issues, I'm not familiar enough with how MI is consumed to know for
sure. Happy to simplify this
to be the same output unconditionally if it makes sense.
>
> > + }
> > + else
> > + {
> > + std::string s = format_pc_offset (offset);
> > + m_uiout->field_string ("offset", s.c_str ());
> > + }
> > m_uiout->text (">:\t");
> > }
> > else
> > diff --git a/gdb/printcmd.c b/gdb/printcmd.c
> > index ae498395436..5fb8c666447 100644
> > --- a/gdb/printcmd.c
> > +++ b/gdb/printcmd.c
> > @@ -567,7 +567,7 @@ print_address_symbolic (struct gdbarch *gdbarch, CORE_ADDR addr,
> > gdb_puts ("<", stream);
> > fputs_styled (name.c_str (), function_name_style.style (), stream);
> > if (offset != 0)
> > - gdb_printf (stream, "%+d", offset);
> > + gdb_puts (format_pc_offset (offset).c_str (), stream);
> >
> > /* Append source filename and line number if desired. Give specific
> > line # of this addr, if we have it; else line # of the nearest symbol. */
> > diff --git a/gdb/testsuite/gdb.base/radix.c b/gdb/testsuite/gdb.base/radix.c
> > new file mode 100644
> > index 00000000000..191c374d466
> > --- /dev/null
> > +++ b/gdb/testsuite/gdb.base/radix.c
> > @@ -0,0 +1,31 @@
> > +/* This testcase is part of GDB, the GNU debugger.
> > +
> > + Copyright 2013-2026 Free Software Foundation, Inc.
> The copyright year can be only 2026.
ack
> > +
> > + This program is free software; you can redistribute it and/or modify
> > + it under the terms of the GNU General Public License as published by
> > + the Free Software Foundation; either version 3 of the License, or
> > + (at your option) any later version.
> > +
> > + This program is distributed in the hope that it will be useful,
> > + but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + GNU General Public License for more details.
> > +
> > + You should have received a copy of the GNU General Public License
> > + along with this program. If not, see <http://www.gnu.org/licenses/>. */
> > +
> > +#include <unistd.h>
> > +#include <stdio.h>
> > +
> > +int v;
> > +
> > +int main()
> Testsuite should also follow the coding style, so main should be in
> column 0 of the next line and have a space between function name and
> parenthesis.
ack
> > +{
> > + puts("hello world");
> > + /* Don't let the test case run forever. */
> > + alarm (60);
>
> This feels overly complex for what you want to test. Is there any reason
> why a simple
>
> int
> main ()
> {
> return 0;
> }
>
> wouldn't be enough for the test?
I just duplicated and modified another test program right next to this
one, I will trim it down and
update the styling and copyright as requested. Just need to have
enough in the function for
there to be enough instructions for testing the offsets.
>
> > +
> > + for (;;)
> > + ;
> > +}
> > diff --git a/gdb/testsuite/gdb.base/radix.exp b/gdb/testsuite/gdb.base/radix.exp
> > index 7a4320bbf36..99256b98df3 100644
> > --- a/gdb/testsuite/gdb.base/radix.exp
> > +++ b/gdb/testsuite/gdb.base/radix.exp
> > @@ -17,6 +17,11 @@
> > # This file was written by Fred Fish. (fnf@cygnus.com)
> > # And rewritten by Michael Chastain (mec.gnu@mindspring.com)
> >
> > +standard_testfile
> > +
> > +if {[build_executable "failed to prepare" $testfile $srcfile debug]} {
> > + return -1
> > +}
> >
> > # Start with a fresh gdb.
> >
> > @@ -189,3 +194,32 @@ gdb_test "set radix 7" \
> > gdb_test "show output-radix" \
> > "Default output radix for printing of values is 10\\." \
> > "output radix unchanged after rejection through set radix command"
> > +
> > +with_test_prefix "pc offset radix" {
> > + clean_restart $testfile
> > +
> > + if { ![runto_main] } {
> > + return -1
> > + }
> > +
> > + proc test_pc_offset_radix { oradix offset_re } {
> > + global gdb_prompt
> > +
> > + gdb_test "set output-radix $oradix" \
> > + "Output radix now set to decimal $oradix.*\\."
> > +
> > + set test "x/10i main with output-radix $oradix"
> > + gdb_test_multiple "x/10i main" $test {
> I wonder if using x/i or x/2i would be enough. I think it's good to
> minimize the amount of stuff emitted by GDB, so that we don't fill a
> buffer on slow/overworked machines and get unreliable tests
I wanted to get enough output for the test to fully verify that the
right octal was being
used (rather than an (unlikely) formatting issue; ie, offsets >
0n10/0xa). I'll make a tweak here
to decrease the buffer size while still validating this behavior.
> > + -re "<main\\+$offset_re>:\[^\r\n\]*\r\n(?:\[^\r\n\]*\r\n)*$gdb_prompt $" {
>
> This can be simplified in a few ways. First, you can use -wrap to wrap
> your regular expression in the stuff that gdb_test adds around it, so
> you won't need to add $gdb_prompt at the end and some stuff at the
> start, and second, the whole "\[^\r\n\]*\r\n(?:\[^\r\n\]*\r\n)*" is just
> "any number of lines with any amount of characters", so there's no
> reason to not use a simple ".*" there. We just avoid .* when the exact
> amount of lines, or that something is in the same line, is important,
> which isn't the case in this test.
Ah perfect, thanks. Will adjust.
>
> > + pass $gdb_test_name
> > + }
> > + }
> > + }
> > +
> > + test_pc_offset_radix 8 {0[0-7]{2,}}
> > + test_pc_offset_radix 10 {[1-9][0-9]+}
> This regex fails if the number is exactly 0, but if you use multiple
> instructions and -wrap, I don't think it is a big deal....
Yep, I'll make some tweaks here.
> > + test_pc_offset_radix 16 {0x[0-9a-f]{2,}}
> > +
> > + gdb_test "set output-radix 10" "Output radix now set to decimal 10.*\\." \
> > + "restore output-radix"
> > +}
> > diff --git a/gdb/valprint.c b/gdb/valprint.c
> > index 62b1b33bb66..ea4bece0416 100644
> > --- a/gdb/valprint.c
> > +++ b/gdb/valprint.c
> > @@ -171,6 +171,16 @@ show_output_radix (struct ui_file *file, int from_tty,
> > value);
> > }
> >
>
> There should be a comment here like
>
> /* See valprint.h. */
ack
>
> > +std::string
> > +format_pc_offset (int offset)
> > +{
> > + const char *sign = (offset < 0) ? "-" : "+";
> > + ULONGEST uoffset = (offset < 0) ? -(ULONGEST) offset : (ULONGEST) offset;
> > +
> > + std::string body = int_string (uoffset, output_radix, 0, 0, 1);
>
> since uoffset is ULONGEST, you should use pulongest. However, I don't
> even think you need this extra variable, you can just pass (offset < 0)
> -offset : offset to the int_string call.
>
> > + return std::string (sign) + body;
> why not declare sign as an std::string? I think it would make things a
> little more readable.
> > +}
> > +
> > /* By default we print arrays without printing the index of each element in
> > the array. This behavior can be changed by setting PRINT_ARRAY_INDEXES. */
> >
> > diff --git a/gdb/valprint.h b/gdb/valprint.h
> > index 0ce3e0781f6..5511707cba3 100644
> > --- a/gdb/valprint.h
> > +++ b/gdb/valprint.h
> > @@ -320,6 +320,12 @@ extern int build_address_symbolic (struct gdbarch *,
> > int *line,
> > int *unmapped);
> >
> > +/* Format OFFSET, the offset portion of a "<symbol+offset>" display, as
> > + a string with an explicit sign prefix ("+" or "-"). The numeric
> > + portion is rendered using the current "output-radix". */
> > +
> > +extern std::string format_pc_offset (int offset);
> > +
> > /* Check to see if RECURSE is greater than or equal to the allowed
> > printing max-depth (see 'set print max-depth'). If it is then print an
> > ellipsis expression to STREAM and return true, otherwise return false.
>
>
> --
> Cheers,
> Guinevere Larsen
> It/she
>
next prev parent reply other threads:[~2026-05-08 23:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 21:37 Zander Work
2026-05-08 13:44 ` Guinevere Larsen
2026-05-08 22:59 ` Zander Work [this message]
2026-05-13 16:28 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAB3ousCKmytOaWJMNC4kBm8oBqmUWOywg_bEnTutmm9M6vty_Q@mail.gmail.com \
--to=zdw@google.com \
--cc=gdb-patches@sourceware.org \
--cc=guinevere@redhat.com \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox