`orr` with `xzr` does not disassemble as `mov` about bad64 HOT 4 CLOSED

Pulled in the upstream changes in 1b5f5db, this should be resolved now. Thanks for the report!

from bad64.

This is a good question, I'm not sure. We pipe the mnemonic directly down from binj'a arm64 disassembler so this would actually be an upstream bug if so. I've cc'd this issue to them and will let you know. Thanks for the possible bug report!

from bad64.

CASE 1:

orr w0, wzr, w1, lsl #0x15 assembles to e0 57 01 2a and:

           us: orr w0, wzr, w1, lsl #0x15
     capstone: orr w0, wzr, w1, lsl #0x15
   libopcodes: mov w0, w1, lsl #0x15
         llvm: orr w0, wzr, w1, lsl #0x15

So in a game of survivor, libopcodes is voted off the island. But is the majority right? According to spec, this is encoding named ENC_ORR_32_LOG_SHIFT and the MOV alias is preferred when shift == '00' && imm6 == '000000' && Rn == '11111'. Here are the fields of the instruction, showing that imm6 violates the preference:

+----+-----+-------+-------+---+-------+--------+-------+-------+
| SF | OPC |   -   | SHIFT | N |   RM  |  IMM6  |   RN  |   RD  |
+----+-----+-------+-------+---+-------+--------+-------+-------+
| 0  |  01 | 01010 |   00  | 0 | 00001 | 010101 | 11111 | 00000 |
+----+-----+-------+-------+---+-------+--------+-------+-------+

CASE 2:

orr x0, xzr, x1, lsl #0x15 assembles to e0 57 01 aa and the committee says:

           us: orr x0, xzr, x1, lsl #0x15
     capstone: orr x0, xzr, x1, lsl #0x15
   libopcodes: mov x0, x1, lsl #0x15
         llvm: orr x0, xzr, x1, lsl #0x15

Voted off again! By why? This one, according to spec, is same as above, but 64 bit, named ENC_ORR_64_LOG_SHIFT with the same alias preferences. The fields are:

+----+-----+-------+-------+---+-------+--------+-------+-------+
| SF | OPC |   -   | SHIFT | N |   RM  |  IMM6  |   RN  |   RD  |
+----+-----+-------+-------+---+-------+--------+-------+-------+
| 1  |  01 | 01010 |   00  | 0 | 00001 | 010101 | 11111 | 00000 |
+----+-----+-------+-------+---+-------+--------+-------+-------+

And again imm6 violates the preference condition needed for this to be aliased as mov.

CASE 3:

orr x0, xzr, #0x3333333333333333 assembles to e0 e7 00 b2 and the committee speaks:

           us: orr x0, xzr, #0x3333333333333333
     capstone: orr x0, xzr, #0x3333333333333333
   libopcodes: mov x0, #0x3333333333333333
         llvm: mov x0, #0x333333333333333

A split, cool! We'll defer to the spec as usual. This is en encoding named ENC_ORR_64_LOG_IMM and the alias condition is Rn == '11111' && ! MoveWidePreferred(sf, N, imms, immr). Damn, so the task is complicated with a descent into the logic of function MoveWidePreferred(). First pick out the fields:

+----+-----+--------+---+--------+--------+-------+-------+
| SF | OPC |   -    | N |  IMMR  |  IMMS  |   RN  |   RD  |
+----+-----+--------+---+--------+--------+-------+-------+
| 1  |  01 | 100100 | 0 | 000000 | 111001 | 11111 | 00000 |
+----+-----+--------+---+--------+--------+-------+-------+

With the Rn == 11111 conjunct satisfied, we need only to satisfy ! MoveWidePreferred(1b, 0b, 111001b, 000000b). Equivalently, showing MoveWidePreferred() returning true justifies the alias not being used. The pseudocode is given in the spec HERE and has lines:

    // element size must equal total immediate size
    if sf == '1' && immN:imms != '1xxxxxx' then
        return FALSE;

With sf==1b and immN:imms = 0111001b, this returns false. We have a bug I think!

So what went wrong? Well our disassembler doesn't capture MoveWidePreferred()'s behavior well enough. There are often ambiguities when porting pcode to C and the intent of the modulus operations that follow the above check was implemented with NetBSD's aarch64 disassembler as reference, but the two return false logic shortcuts are not present. I checked an earlier version of the spec from 2020-03, hoping for an excuse, but the checks are there, so it's a plain oversight on my part.

I'll get a fix out soon, thanks for the report!

from bad64.

Actually, MoveWidePreferred() affects the assigned encoding name of an incoming instruction word. So in the 3rd case above, it's no longer ENC_ORR_64_LOG_IMM but MOV_ORR_64_LOG_IMM after the correction.

from bad64.