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
pulled in.

Docs are here btw:
https://www.gnu.org/software/gnulib/manual/html_node/sprintf.html

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.

https://sourceware.org/pipermail/gdb-patches/2022-February/185967.html

The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e

commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
Author: Tom Tromey <tromey@adacore.com>
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:
    
        '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

Fixed.

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,

    import gdb
    
    class Hexfloat (gdb.Function):
      """Converts a float to a hex representation."""
    
      def __init__ (self):
        super (Hexfloat, self).__init__ ("hexfloat")
    
      def invoke (self, x):
        return float.hex(float(x))
    
    Hexfloat()

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. ***