Given the following `main.c` file ``` #include <stdio.h> static int val = 0x2a; int main() { printf("%d\n", val); } ``` And running those commands: ``` ninja -C build m68k-linux-gnu-gcc main.c -static -o m68k build/qemu-m68k \ -plugin build/tests/tcg/plugins/libmem.so,print-accesses=on \ -d plugin m68k |& grep ',main,.*0x0000002a' ``` Download binary directly: [m68k](/uploads/1c700c04f455da2f9e045ea87e84225d/m68k) The expected output is: ``` 0x800003e4,main,0x80071208,0x0,32,load,0x0000002a 0x800003ea,main,0xc07ffed8,0x0,32,store,0x0000002a ``` On x86_64 host, it's working on expected. However, on aarch64 host, it's reading the value with a different endianness: ``` 0x800003ea,main,0x80071210,0x0,32,load,0x2a000000 0x800003f0,main,0xc0800178,0x0,32,store,0x2a000000 ``` I initially suspected a bug on plugin side. The value we return is stored in `current_cpu->neg.plugin_mem_value_low`, which is written from `plugin_gen_mem_callbacks_i32`, from `tcg_gen_qemu_{ld,st}_i32_int` using: ``` tcg_gen_st_i32(val, tcg_env, offsetof(CPUState, neg.plugin_mem_value_low) - sizeof(CPUState) + (HOST_BIG_ENDIAN * 4)); ``` This value seems to be already endian swapped when writing it. Thus, I suspect an issue in tcg backend on aarch64 instead.