MSP430: byte operations sign-extend into registers instead of zero-extending

Start in arch/msp430/src/lift.rs and inspect the byte-handling arms, including Instruction::Mov, where the issue identifies il.sx(2, ...) as suspect. Load sx_repro.bin or use the provided printf command, then compare LLIL at offset 0 and the resulting HLIL value against the documented zero-extension behavior. Done means byte register operations produce 0x80 + arg1 rather than 0xff80 + arg1.

Version and Platform (required):

• Binary Ninja Version: 5.0.7648
• Edition: Non-Commercial
• OS: Ubuntu
• OS Version: 24.04
• CPU Architecture: x64

Bug Description:
A byte instruction with a register destination is lifted with a sign-extension. Per slau144 §3.2.5, Figure 3-7 (Byte-Register Operation), the high byte of the destination register is filled with 0h — byte operations zero-extend into registers.

The result is an incorrect constant in HLIL for any byte value with bit 7 set.

Steps To Reproduce:
printf '\x7b\x40\x80\x00\x0f\x5b\x30\x41' > sx_repro.bin or open sx_repro.bin attached and look at sub_0 (if sub_0 does not exist, create a function at 0).

Expected Behavior:
The returned value should be 0x80 + arg1 and not 0xff80 + arg1.
LLIL at offset 0 should not sign-extend.

Confirmed against the mspdebug simulator (v0.22): with r11 = 0xdead and r15 = 0x1234 set beforehand, mov.b #0x80, r11 leaves r11 = 0x0080. The subsequent add r11, r15 gives 0x12b4.

Screenshots/Video Recording:

Binary:
sx_repro.zip

Suspected cause (hypothesis):
The byte arms in arch/msp430/src/lift.rs use il.sx(2, ...) where il.zx(2, ...) is required — e.g. in Instruction::Mov:

OperandWidth::Byte => il
                    .sx(2, lift_source_operand(inst.source(), size, il))
                    .build()

This appears in several instruction arms, so the fix is likely needed in more than one place.