x/arch/arm/armasm: second source register is calculated incorrectly

[williamweixiao]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

golang.org/x/arch/arm

What operating system and processor architecture are you using (go env)?

Ubuntu 16.04.1 LTS and ARM64

What did you do?

Disassemble following two instructions
937facb
d6530d61

What did you expect to see?

STREXD.LT [R12], R4, R3, R7
LDRD.VS [SP, -R6], R6, R5

What did you see instead?

STREXD.LT [R12], R3, R3, R7
LDRD.VS [SP, -R6], R5, R5

[gopherbot]

CL https://golang.org/cl/37032 mentions this issue.

[williamweixiao]

it's hard to expose the bug by test with gnu syntax which just print out the first source register. so i add test with go assembly syntax which print both source registers.

[rsc]

I don't believe those are valid instructions. The ARM manual I am looking at says that when Rt2 is not explicitly encoded in those instructions, Rt must be even and not R14. So +1 and |1 are the same. I think I used |1 specifically because it wouldn't look like +1 if someone did accidentally write one of those instructions. Printing the same register again is at least a hint that something is wrong, instead of silently pretending everything is OK.

Do you know something I don't? Do those instructions now accept odd Rt values as well?

[williamweixiao]

Yes, you are right according to ARMv7 manual.
The latest ARMv8 (i mean AArch32) manual somehow release the even-numbered constraint as below:

If Rt<0> == '1', then one of the following behaviors must occur:
• The instruction is UNDEFINED.
• The instruction executes as NOP.
• The instruction executes with the additional decode: Rt<0> = '0'.
• The instruction executes with the additional decode: t2 = t.
• The instruction executes as described, with no change to its behavior and no additional side effects.

Considering that both |1 and +1 are valid for different implementations. I suggest emitting UNDEF or INVALID for more explicit hint.

[williamweixiao]

I just test on Cortex-A57 (Huawei) and find that the implementation choose:

• The instruction executes with the additional decode: Rt<0> = '0'

[rsc]

It's fine to change this to some kind of undefined. Please don't change it to +1 or ^1 or something else silently different.