As part of a research project testing the accuracy of the SLEIGH specifications compared to real hardware, we observed an unexpected behaviour in the ldrexd instruction for AArch32 (ARM:LE:32:v8).
According to the manual, the expected behaviour is to derive an address from a base register value, load a 64-bit doubleword from memory and write it to two registers. However, when the source register and the first destination register are aliased, it causes the second word to load at an incorrect address, i.e, the value retrieved from the first load.
As part of a research project testing the accuracy of the SLEIGH specifications compared to real hardware, we observed an unexpected behaviour in the
ldrexdinstruction for AArch32 (ARM:LE:32:v8).According to the manual, the expected behaviour is to derive an address from a base register value, load a 64-bit doubleword from memory and write it to two registers. However, when the source register and the first destination register are aliased, it causes the second word to load at an incorrect address, i.e, the value retrieved from the first load.
e.g, for AArch32 with,
Instruction:
0x9f0fb0b1, ldrexdlt r0,r1,[r0]initial_memory:{ "0x9C631430": [ 0x44, 0x4e, 0x44, 0x96, 0x6c, 0x6b, 0x3a, 0x5e ] }initial_registers:{ "r0": 0x9c631430, "NG": 0x1, "OV": 0x0 }We get:
Hardware:
{ "r0": 0x96444e44, "r1": 0x5e3a6b6c }Patched Spec:{ "r0": 0x96444e44, "r1": 0x5e3a6b6c }Existing Spec:{ "r0": 0x96444e44, "r1": 0x75fbb439 }However, existing Thumb mode (
ARM:LE:32:v8T) semantics are correct.Note: The patched spec does not introduce any disassembly changes to the best of our knowledge.