Floating-point constants aren't being displayed as floating-point

[pjcreath]

Version and Platform (required):

• Binary Ninja Version: 5.2.8034-dev
• Edition: Non-Commercial
• OS: macOS
• OS Version: 15
• CPU Architecture: x64

Bug Description:
For some reason, all the floating-point constants I'm encountering are being displayed as large hex values, perhaps because they were constructed via multiple underlying instructions?

Steps To Reproduce:

1. See binary below, notice floating-point constants at 1000386c4, 10003873c, 1000038750 are shown as hex.
2. Right-click on them and select "Display as > Double" (since they're wrapped in float.d(0xCONSTANT)).
3. See the actual values.

Expected Behavior:
I would have expected BN to automatically display something inside float.d(CONSTANT) as a double and float.s(CONSTANT) as a single.

Screenshots/Video Recording:
n/a

Binary:
See zodiac magic falls perfectly.

Additional Information:
When fixed, floating-point constants that correspond to integer values don't have any visible indication that they are floating-point rather than integers: i.e. instead of simply "90" it would be helpful to see something like "90f" or "90." or "90.0".

[plafosse]

This actually looks like a armv8 lifting bug. float.d is saying take this integer and create a float. While what it should be saying is the opposite. Broken code is the following:

		case ENC_FMOV_D64_FLOAT2INT:
		case ENC_FMOV_H32_FLOAT2INT:
		case ENC_FMOV_H64_FLOAT2INT:
		case ENC_FMOV_S32_FLOAT2INT:
			// <Vd> <- <Rn> (copy from general register to FP register, with no conversion)
			il.AddInstruction(
			    ILSETREG_O(operand1, il.IntToFloat(REGSZ_O(operand1), ILREG_O(instr.operands[1]))));
			break;

I think the fix is to convert the IntToFloat to FloatRaw

[galenbwill]

FloatConstRaw will not work since it takes a uint64_t value as the "operand".

the FLOAT2INT in the encoding names is misleading here -- the actual instruction is FMOV, and moves the raw bits of a floating point value from an integer register to a floating point register, with no conversion (the mirror operation, which moves from floating point register to integer register with no conversion, also has FLOAT2INT in its encoding name).

dogbolt shows that this C code:

double test(double _v0)
{
    double v0 = (double)_v0;
    uint64_t v1 = (double)90.0;
    uint64_t v8 = (double)v1 / (double)v0;
    return v8;
}

compiles almost exactly to the instruction sequence in the uploaded binary, which is:

1000386bc  0800d0d2   mov     x8, #0x800000000000
1000386c0  c80ae8f2   movk    x8, #0x4056, lsl #0x30  {0x4056800000000000}
1000386c4  0101679e   fmov    d1, x8
1000386c8  2818601e   fdiv    d8, d1, d0

Once we force display-as floating point, the Pseudo-C in the uploaded binary is almost the same as the C code above, except it puts uint64_t casts in around the division:

1000386b8            (uint64_t)v0 = (double)(uint64_t)v0;
1000386c4            (uint64_t)v1 = (double)90;
1000386c8            v8 = (uint64_t)v1 / (uint64_t)v0;

The HLIL however, shows that the division is floating-point, again, after forcing display-as floating point on the constant:

1000386b8            v0.q = float.d(v0.q)
1000386c4            v1.q = float.d(90)
1000386c8            v8 = v1.q f/ v0.q

So I would contend that the lifting is in fact correct, but the Pseudo-C presentation is inaccurate wrt the HLIL.

But the original question posed in the issue, why aren't the constants displayed as floating point by default, still stands.

[galenbwill]

I've given this some further consideration, and decided to see what happens if I follow the spec literally, and remove the IntToFloat:

FMOV (general)
Floating-point move to or from general-purpose register without conversion

HLIL:

1000386b8            v0.q = float.d(v0.q)
1000386c4            v1.q = 0x4056800000000000
1000386c8            v8 = 90.0 f/ v0.q

Pseudo-C:

1000386b8            (uint64_t)v0 = (double)(uint64_t)v0;
1000386c4            (uint64_t)v1 = 0x4056800000000000;
1000386c8            v8 = 90.0 / (uint64_t)v0;

The float.d in the first line (of HLIL) correctly reflects the UCVT at 1000386b8.
The constant on the RHS of the initialization of v1 at 1000386c4 is still shown as an integer, but when it is then used in the division at 1000386c8, we see that it is shown as a floating point constant (without forcing display-as).

Consider another example:

100039b0c  c8d093d2   mov     x8, #0x9e86
100039b10  e888aaf2   movk    x8, #0x5447, lsl #0x10
100039b14  683fc4f2   movk    x8, #0x21fb, lsl #0x20
100039b18  2801e8f2   movk    x8, #0x4009, lsl #0x30  {0x400921fb54479e86}
100039b1c  0001679e   fmov    d0, x8  {0x400921fb54479e86}
100039b20  4008601e   fmul    d0, d2, d0
100039b24  0800d0d2   mov     x8, #0x800000000000
100039b28  c80ce8f2   movk    x8, #0x4066, lsl #0x30  {0x4066800000000000}
100039b2c  0101679e   fmov    d1, x8  {0x4066800000000000}
100039b30  0018611e   fdiv    d0, d0, d1

HLIL:

100039b1c        v0.q = 0x400921fb54479e86
100039b20        v0.q = v2.q f* 3.1415926536900001
100039b2c        v1.q = 0x4066800000000000
100039b30        v0.q = v0.q f/ 180.0

Pseudo-C:

100039b1c        (uint64_t)v0 = 0x400921fb54479e86;
100039b20        (uint64_t)v0 = (uint64_t)v2 * 3.1415926536900001;
100039b2c        (uint64_t)v1 = 0x4066800000000000;
100039b30        (uint64_t)v0 = (uint64_t)v0 / 180.0;

Again, the constants are rendered as floats, but not until they appear as inlined values when the register assigned to them are used.

So, is this better or worse than the current situation, as described above in my previous comment?