From: Tom Tromey via Gdb-patches <gdb-patches@sourceware.org>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tromey@adacore.com>
Subject: [PATCH] Change how "print/x" displays floating-point value
Date: Thu, 17 Feb 2022 14:29:57 -0700 [thread overview]
Message-ID: <20220217212957.1747537-1-tromey@adacore.com> (raw)
Currently, "print/x" will display a floating-point value by first
casting it to an integer type. This yields weird results like:
(gdb) print/x 1.5
$1 = 0x1
This has confused users multiple times -- see PR gdb/16242, where
there are several dups. I've also seen some confusion from this
internally at AdaCore.
The manual says:
'x'
Regard the bits of the value as an integer, and print the integer
in hexadecimal.
... which seems more useful. So, perhaps what happened is that this
was incorrectly implemented (or maybe correctly implemented and then
regressed, as there don't seem to be any tests).
This patch fixes the bug.
There was a previous discussion where we agreed to preserve the old
behavior:
https://sourceware.org/legacy-ml/gdb-patches/2017-06/msg00314.html
However, I think it makes more sense to follow the manual.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242
---
gdb/printcmd.c | 9 ++-------
gdb/testsuite/gdb.base/printcmds.exp | 7 +++++--
gdb/testsuite/gdb.base/return-nodebug.exp | 7 ++++++-
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/gdb/printcmd.c b/gdb/printcmd.c
index 6f9be820b0c..30de1927d39 100644
--- a/gdb/printcmd.c
+++ b/gdb/printcmd.c
@@ -426,19 +426,14 @@ print_scalar_formatted (const gdb_byte *valaddr, struct type *type,
len = newlen;
}
- /* Historically gdb has printed floats by first casting them to a
- long, and then printing the long. PR cli/16242 suggests changing
- this to using C-style hex float format.
-
- Biased range types and sub-word scalar types must also be handled
+ /* Biased range types and sub-word scalar types must be handled
here; the value is correctly computed by unpack_long. */
gdb::byte_vector converted_bytes;
/* Some cases below will unpack the value again. In the biased
range case, we want to avoid this, so we store the unpacked value
here for possible use later. */
gdb::optional<LONGEST> val_long;
- if (((type->code () == TYPE_CODE_FLT
- || is_fixed_point_type (type))
+ if ((is_fixed_point_type (type)
&& (options->format == 'o'
|| options->format == 'x'
|| options->format == 't'
diff --git a/gdb/testsuite/gdb.base/printcmds.exp b/gdb/testsuite/gdb.base/printcmds.exp
index 37632985a07..2d0aafd6d8b 100644
--- a/gdb/testsuite/gdb.base/printcmds.exp
+++ b/gdb/testsuite/gdb.base/printcmds.exp
@@ -158,8 +158,11 @@ proc test_float_rejected {} {
# Regression test for PR gdb/21675
proc test_radices {} {
gdb_test "print/o 16777211" " = 077777773"
- gdb_test "print/d 1.5" " = 1"
- gdb_test "print/u 1.5" " = 1"
+
+ # See PR gdb/16242 for this.
+ gdb_test "print/d 1.5f" " = 1069547520"
+ gdb_test "print/u 1.5f" " = 1069547520"
+ gdb_test "print/x 1.5f" " = 0x3fc00000"
gdb_test "print/u (char) -1" " = 255"
gdb_test "print/d (unsigned char) -1" " = -1"
diff --git a/gdb/testsuite/gdb.base/return-nodebug.exp b/gdb/testsuite/gdb.base/return-nodebug.exp
index 6fd41bee884..1cce09d2fc4 100644
--- a/gdb/testsuite/gdb.base/return-nodebug.exp
+++ b/gdb/testsuite/gdb.base/return-nodebug.exp
@@ -38,7 +38,12 @@ proc do_test {type} {
"advance to marker"
# And if it returned the full width of the result.
- gdb_test "print /d t" " = -1" "full width of the returned result"
+ if {$type == "float" || $type == "double"} {
+ set flag ""
+ } else {
+ set flag "/d"
+ }
+ gdb_test "print $flag t" " = -1" "full width of the returned result"
}
}
}
--
2.31.1
next reply other threads:[~2022-02-17 21:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 21:29 Tom Tromey via Gdb-patches [this message]
2022-02-17 23:17 ` Andrew Burgess via Gdb-patches
2022-02-18 16:44 ` Tom Tromey via Gdb-patches
2022-02-18 17:02 ` Eli Zaretskii via Gdb-patches
2022-03-10 17:27 ` Tom Tromey via Gdb-patches
2022-03-10 17:54 ` Eli Zaretskii via Gdb-patches
2022-03-10 19:19 ` Tom Tromey via Gdb-patches
2022-02-18 17:41 ` Andreas Schwab
2022-02-19 10:05 ` Andrew Burgess via Gdb-patches
2022-03-10 17:30 ` Tom Tromey via Gdb-patches
2022-03-10 17:30 ` Tom Tromey via Gdb-patches
2022-03-10 18:23 ` Andreas Schwab
2022-03-10 20:39 ` Tom Tromey via Gdb-patches
2022-03-10 20:53 ` Andreas Schwab
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=20220217212957.1747537-1-tromey@adacore.com \
--to=gdb-patches@sourceware.org \
--cc=tromey@adacore.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