Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AArch32: ldrexd addr src register aliased as first dest register causing second word load at the value of first load #6590

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Sleigh-InSPECtor
Copy link
Contributor

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.


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.

* fixed addr src register aliased as first dest register of a double word load causing second word load at the value of first load
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature: Processor/ARM Status: Triage Information is being gathered
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants