ARM decompile appears to ignore high-word in movw / movt pair

[pcjc2]

Describe the bug
A clear and concise description of the bug.

Observed in ARM decompile:

4d f6 f0 movw r1 ,#0xd8f0
01
cf f6 ff movt r1 ,#0xffff
71

r1 is set to -10,000 (decimal).

decompule output

iVar3 = 55536;

(NB: iVar3 is typed int32_t)

Expected behavior
A clear and concise description of what you expected to happen.

Decompile should be:

iVar3 = -10000;

Environment (please complete the following information):

• OS: [e.g. macOS 10.14.2]
• Java Version: [e.g. 11.0]
• Ghidra Version: [e.g. 10.1.4]
• Ghidra Origin: [e.g. official GitHub distro, third party distro, locally built]

11.4.2_PUBLIC

[pcjc2]

I think the PCODE looks OK...

   4d  f6  f0       movw            iVar2 ,#55536
             00
                                                  r0  =  INT_ZEXT  0xd8f0 :2
                                                  tmpNG  =  INT_SLESS  r0 , 0:4
                                                  tmpZR  =  INT_EQUAL  r0 , 0:4
    cf  f6  ff       movt            iVar2 ,#0xffff
             70
                                                  $U9ec80 :4 =  INT_ZEXT  0xffff :2
                                                  $U9ed00 :4 =  INT_LEFT  $U9ec80 :4, 16 :4
                                                  $U9ed80 :4 =  INT_AND  r0 , 0xffff :4
                                                  r0  =  INT_OR  $U9ed00 :4, $U9ed80 :4

[GhidorahRex]

Which ARM variant are you using?

[GhidorahRex]

With ARM:LE:32:v8 I see the expected result:

int32_t armTest(void)

{
  return -10000;
}

Disassembly:

        00010946 4d f6 f0 00     movw       r0,#0xd8f0
                                                      r0 = INT_ZEXT 0xd8f0:2
                                                      tmpNG = INT_SLESS r0, 0:4
                                                      tmpZR = INT_EQUAL r0, 0:4
        0001094a cf f6 ff 70     movt       r0,#0xffff
                                                      $Uadb00:4 = INT_ZEXT 0xffff:2
                                                      $Uadb80:4 = INT_LEFT $Uadb00:4, 16:4
                                                      $Uadc00:4 = INT_AND r0, 0xffff:4
                                                      r0 = INT_OR $Uadb80:4, $Uadc00:4

Given that the disassembly in the first part of your post doesn't match the disassembly in the comment, did you modify the instructions? You may need to clear the bytes and re-disassemble.

[pcjc2]

This is with an ARM Cortex M3 microprocessor, Ghidra language is set to ARM:LE:32:Cortex

As regards the discrepancy in my examples - my bad, the function in question had a similar passage that assigned r0 and r1, I mixed my pastes between the two.

As far as I can see, the PCODE matches between my example and yours, - so I'm wondering if the issue lies in the decompiler. The binary I'm working on is no mine to post, otherwise I'd post the whole function, but a summary is below.

The high-word of the register isn't actually used (the signed 32-bit constant loaded in the example is stored into a signed 16-bit variable with a strh.w instruction). It appears the decompiler has perhaps optimized out the assignment of the high "0xffff____" part of the constant. It then displays the assignment as if only the lower word were assigned. As far as the memory contents after execution, both are functionally identical I think - just what we see in the decompilation is misleading.

The code in question should decompile to something like:

int32_t iVar3;

[...]

if (iVar3 < -10000) {
iVar3 = -10000;
}

int16_t_dest_var = (int16_t) iVar3;

(Except we see the conditional assignment being iVar3 = 0xd8f0;)

[GhidorahRex]

It seems likely that the high-word assignment is being optimized out if it's only using the lower 16-bits. When the decompiler sees two separate 16-bit assignments and then a 16-bit store, it will try to treat it as a 16-bit variable. This helps for vectored instructions when there are multiple values stored in a single large register.

[pcjc2]

I agree "optimization" is the likely cause. Do you think it would be possible to consider the decompiled output as a weak "consumer" of at least the sign bit? It seems to make more sense to show the variable assignment as the underlying assembly code actually would set physical register - even if the high-bits are later discarded.

Is the "optimization" part of the de-compilation a fundamentally required step, or something that could be optional? Is its purpose mainly to de-obfuscate deliberately tricky code?