Ghidra: [M68000] decompiler cannot create correct array assignments

[sma]

The M68000 decompiler incorrectly translates the following code fragment:

      0402cf06 30 2d ff      move.w    (i,A5),D0w
               fe
      0402cf0a 48 c0         ext.l     D0
      0402cf0c e3 80         asl.l     #0x1,D0
      0402cf0e 41 f9 04      lea       (SHORT_ARRAY_0403f996).l,A0                = 
               03 f9 96
      0402cf14 32 2d ff      move.w    (i,A5),D1w
               fe
      0402cf18 48 c1         ext.l     D1
      0402cf1a e3 81         asl.l     #0x1,D1
      0402cf1c 43 f9 04      lea       (SHORT_ARRAY_04042364).l,A1                = 
               04 23 64
      0402cf22 33 b0 08      move.w    (0x0,A0,D0*0x1),(0x0,A1,D1*0x1)=>SHORT_AR  = 
               00 18 00

It generates a "self" assignment, ignoring the source:

SHORT_ARRAY_04042364[i] = SHORT_ARRAY_04042364[i];

This would be correct:

SHORT_ARRAY_04042364[i] = SHORT_ARRAY_0403f996[i]

Somehow it "forgets" the A0 address and uses the A1 address twice.

Environment (please complete the following information):

• OS: macOS 10.15.2
• Java Version: 13.0
• Ghidra Version: 9.1.1

[mumbel]

$U60:4 = INT_MULT D0, 1:4
$Uf0:4 = INT_ADD A0, 0:4
$U110:4 = INT_ADD $Uf0, $U60
$U60:4 = INT_MULT D1, 1:4
$Uf0:4 = INT_ADD A1, 0:4
$U110:4 = INT_ADD $Uf0, $U60
$Ua70:2 = LOAD ram($U110)
$U1010:2 = COPY $Ua70
STORE ram($U110), $U1010
$Ua70:2 = LOAD ram($U110)
NF = INT_SLESS $Ua70, 0:2
$Ua70:2 = LOAD ram($U110)
ZF = INT_EQUAL $Ua70, 0:2
VF = COPY 0:1
CF = COPY 0:1

yeah, its blowing away the A0 in $U110 for the A1 without ever saving it off.

[GhidorahRex]

The issue here is on line 1080 of the sleigh file. Both eaw and e2w use the sub-constructor extw and so the two build instructions squash one another. Writing eaw to a local variable before building e2w seems to correct the issue. I'll try to get a fix in review shortly.

[mumbel]

@GhidorahRex that's what I was thinking as well and almost made a PR, but then thought is this a larger fix in PCODE generation. Obviously its not every build x; build y;, is this just a side effect that needs to be managed in SLEIGH?

[GhidorahRex]

@mumbel - it is definitely a larger issue to be addressed. This is just a backstop until we can address the bigger sleigh compiler issue.

[GhidorahRex]

Fixed in 4c81e6837fb22af23ca74696435029f3c30ed856