There should be a print format for displaying float values in hex. /x doesn't work, it converts the value to integer first.
I think it would make sense to repurpose /x, because I don't see much
value in how that currently handling floating point.
There is /z format, which for floating-point values appears to print raw data. The only problem is that this isn't documented. Instead, `help x` says "x(hex)" and "z(hex, zero padded on the left)", without mentioning that the former converts to integer while the latter prints true raw value.
I guess the fix for this would be to make the documentation correct and to add some tests checking that the documentation matches actual behavior.
(In reply to Ruslan from comment #2)
> There is /z format, which for floating-point values appears to print raw
> data. The only problem is that this isn't documented. Instead, `help x` says
> "x(hex)" and "z(hex, zero padded on the left)", without mentioning that the
> former converts to integer while the latter prints true raw value.
> I guess the fix for this would be to make the documentation correct and to
> add some tests checking that the documentation matches actual behavior.
I think that would be good to do, but hex float is not the same as
printing the raw bits in hex.
Ah, I misunderstood this bug report.
This has been filed a few times; I'm picking this one as the canonical
bug since it mentions the /z thing.
*** Bug 25983 has been marked as a duplicate of this bug. ***
*** Bug 15318 has been marked as a duplicate of this bug. ***
*** Bug 16687 has been marked as a duplicate of this bug. ***
/z is really the same as /x, just with padding.
This is a bit of a pain to implement, since according to gnulib
some host printf implementations don't support %a.
Doesn't gnulib already provide an implementation of sprintf function family? Or do you mean gnulib's sprintf doesn't implement %a on some architectures?
Actually I misread the gnulib docs -- it does fix this.
I didn't check to see if gdb already uses this module.
I added sprintf-posix to gdb's gnulib list and re-imported,
and there weren't any changes. So I suppose it was already
Docs are here btw:
So I think we're ok using %a for ordinary things.
However there's also the question of target-float.c.
(In reply to Tom Tromey from comment #13)
> I added sprintf-posix to gdb's gnulib list and re-imported,
> and there weren't any changes. So I suppose it was already
> pulled in.
LOL I used the wrong tree.
This pulls in a bunch more stuff, so I wonder whether it's
appropriate at this stage.
Actually I've come around to the idea that p/x should just
reinterpret the bits and print those exactly.
It's what the manual implies, for one thing.
The master branch has been updated by Tom Tromey <email@example.com>:
Author: Tom Tromey <firstname.lastname@example.org>
Date: Thu Feb 17 13:43:59 2022 -0700
Change how "print/x" displays floating-point value
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:
Regard the bits of the value as an integer, and print the integer
... 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
However, I think it makes more sense to follow the manual.
That isn't hex float, though.
Since this ticket has been re-opened, I've removed the target-milestone, as this isn't a blocking change for GDB 12 release.
If this is of any help, if you add the following python script and source it,
class Hexfloat (gdb.Function):
"""Converts a float to a hex representation."""
def __init__ (self):
super (Hexfloat, self).__init__ ("hexfloat")
def invoke (self, x):
you can get what you want (I think) with
(gdb) p $hexfloat(123.4567)
$1 = "0x1.edd3a92a30553p+6"
*** Bug 20506 has been marked as a duplicate of this bug. ***