Fix endianness detection that byte-swaps every FP immediate on Windows

[mahmoudimus]

Stacked on #1457. That PR fixes an unrelated, pre-existing CMake 4 failure in the
vcpkg workflow which made this branch's CI red for reasons that had nothing to do with
its contents. The first commit here is #1457; please review only the second.

Summary

Every AArch64 floating-point immediate is byte-swapped on a Windows build. fmov s0, #2.0 produces 0x00000040 instead of 0x40000000.

Reproduced on a VS 2022 build of dev-v1.0, with macOS/AppleClang as a control:

Instruction	Expected	Windows (MSVC)	macOS (AppleClang)
fmov s0, #2.0	0x40000000	0x00000040	0x40000000
fmov s0, #1.0	0x3f800000	0x0000803f	0x3f800000

Both Windows values are exact 32-bit byte swaps of the correct answer.

from triton import *
ctx = TritonContext(ARCH.AARCH64)
ctx.processing(Instruction(0x1000, b"\x00\x10\x20\x1e"))   # fmov s0, #2.0
print(hex(ctx.getConcreteRegisterValue(ctx.registers.v0)))

Root cause

Immediate::Immediate(double, size, endianness) (src/libtriton/arch/immediate.cpp) byte-swaps when the host and the emulated platform disagree on byte order. The host side comes from:

#ifdef LITTLE_ENDIAN // provided by CMake
constexpr auto sys_endianness = triton::arch::LE_ENDIANNESS;
#else
constexpr auto sys_endianness = triton::arch::BE_ENDIANNESS;
#endif

CMake does provide it -- but only to one translation unit:

set_source_files_properties(utils/softfloat.cpp PROPERTIES COMPILE_DEFINITIONS
    ${CMAKE_CXX_BYTE_ORDER}
)

CMAKE_CXX_BYTE_ORDER expands to the literal LITTLE_ENDIAN or BIG_ENDIAN, so utils/softfloat.cpp gets the macro and arch/immediate.cpp never does. What immediate.cpp actually sees is the POSIX definition, which does not mean what the #ifdef assumes.

The check also does not work as an endianness test, independently of that:

• On POSIX <endian.h> defines LITTLE_ENDIAN and BIG_ENDIAN as named constants — 1234 and 4321 — so the macro is always defined regardless of the machine's actual byte order. It reaches this translation unit transitively via <sys/types.h>. The correct spelling would have been #if BYTE_ORDER == LITTLE_ENDIAN. It selects the right branch today only because every platform Triton is built on happens to be little-endian; a big-endian POSIX host would fail the same way Windows does.

• Under MSVC neither the header nor the per-source definition applies, the macro is undefined, and Triton concludes it is running big-endian — so it swaps every FP immediate on a little-endian machine.

Introduced in #1359. The constructor has exactly one caller, the AArch64 FP-immediate decode at aarch64Cpu.cpp:539, so the blast radius is fmov <Sd|Dd|Hd>, #imm on Windows builds.

Fix

Extend the byte order to the whole library rather than a single file, reusing the CMAKE_CXX_BYTE_ORDER this file already relies on, and expose it through the existing triton/config.hpp as TRITON_BIG_ENDIAN. The namespaced name also avoids colliding with the POSIX LITTLE_ENDIAN / BIG_ENDIAN constants, which a global -DLITTLE_ENDIAN would have done.

Absence means little-endian, which is correct for every platform Triton currently targets.

Testing

• macOS arm64: generated config correctly contains /* #undef TRITON_BIG_ENDIAN */; both fmov cases correct; ctest 47/47, no regression.
• Windows x86-64 (VS 2022): both fmov cases correct after the fix.
• Ubuntu 24.04: ctest 47/47.

This has no test covering it in-tree, because UnicornAArch64Semantics — the test that catches it — is currently gated off on Windows. A follow-up PR removes that gate.

[cheatcodezky]

已收到您的邮件，我会尽快回复。

[mahmoudimus]

Heads-up on the red checks here: they are not caused by this PR.

The failing job is Build VCPKG package, and it has failed on every run of that workflow since 2026-06-27 — including patch-1 on 2026-08-12, which predates this branch. The cause is an absolute install(DESTINATION) in src/libtriton/CMakeLists.txt that only becomes an error on CMake >= 4; the workflow uses lukka/get-cmake@latest, so the runner moved to 4.4.2 on its own and nothing in the repository changed.

The line number moves between runs only because commits above it shift it: 378 on patch-1, 385 here. The statement itself is byte-identical to dev-v1.0.

#1457 fixes it, and this branch is now rebased on top of that so it can go green. Note that the workflow runs on these branches are currently held at action_required pending maintainer approval.