Incorrect MLIL when doing partial assignment to a register

[xusheng6]

Binary: quick bird dances boldly

In the following code snippet, the rcx register is first set to 0x12817497a9ff848a, and then the cl is set to 0 or 1:

However, in MLIL we lift that to a complete assignment of the rcx register. Which is incorrect, because the setl instruction does not clear the higher bits of rcx

MLIL:

We can see everything is still correct in LLIL or mapped MLIL, but become incorrect in MLIL:

LLIL:

mapped MLIL:

I checked that the size of the temp0 s< 0x12817497a9ff848a operand is 8, which might have caused the issue. Perhaps we think its size is 8 because both sides being compared are 8 bytes? But that does not really say anything about the size of the comparison result

[xusheng6]

Related to #6976

[plafosse]

Looks like we must not be looking at the BNRegisterInfo.extend information somewhere, as it seems to be correct in arch_x86.cpp

[rssor]

Unless I'm missing something, I think this is correct? At the time where cl is written to, only the bit written into cl will be read (and zero extended) into edx, but the rest of the register is unobserved. I'm guessing that the type is being narrowed to bool by PartialAccessResolver based on that (valid) analysis, and then because the type is narrow analysis is willing to discard it. At MLIL and above, this is justifiable in my view.

[plafosse]

Writing to cl doesn't zero extend, and its marked as such in arch_x86.cpp. My guess is that somewhere in partial access resolver we're not checking the RegisterInfo where we should be.

[xusheng6]

Writing to cl doesn't zero extend, and its marked as such in arch_x86.cpp. My guess is that somewhere in partial access resolver we're not checking the RegisterInfo where we should be.

Ryan explained that, the variable rcx we have in MLIL, is NOT having a direct mapping to the rcx register. He explained that, while technically the rcx register holds a large value, the analysis sees that only the lowest byte of it is being used, so the analysis take advantage of that and generated IL that is semantically equivalent to the behavior of the code

[rssor]

Per discussion, I'm closing as not-a-bug