mips: fix left shift of negative value in DecodeMemMMReglistImm4Lsl2

[Samin061]

Your checklist for this pull request

• I've documented or updated the documentation of every API function and struct this PR changes.
• I've added tests that prove my fix is effective or that my feature works (if possible)

Detailed description

DecodeMemMMReglistImm4Lsl2 decodes the offset of the microMIPS LWM16/SWM16 instructions. The ISA defines the address as:

vAddr = zero_extend(offset||0^2) + GPR[sp]

so the 4-bit offset field is concatenated with two zero bits and then zero-extended. The MMR6 path already treats it as unsigned (fieldFromInstruction_4), but the non-MMR6 path sign-extended the field (SignExtend32((Insn & 0xf), 4)) before the << 2. That was wrong in two ways: whenever the field's top bit is set (field >= 8) the value became negative, so Offset << 2 is a left shift of a negative value (UB), and the decoded offset came out negative instead of the zero-extended value the ISA requires.

ubsan on the unpatched tree:

arch/Mips/MipsDisassembler.c:2432:37: runtime error: left shift of negative value -8

Fix is to zero-extend the field to match both the ISA and the MMR6 path. The shift is then always applied to a non-negative value, so the UB is gone and the offset is correct.

Test plan

Added test_ub_shift_mips_mm_reglist to tests/integration/test_poc.c, next to the existing test_ub_shift_sh_dsp_p signed-shift regression. Building with -fsanitize=undefined -fno-sanitize-recover=undefined and running test_poc aborts at MipsDisassembler.c:2432 before the change and exits cleanly after. cstool micromips 4508 now prints lwm16 $s0, $ra, 0x20($sp) (the zero-extended 8 << 2 == 0x20).

[Rot127]

If I see this correctly in the ISA, is the offset first shifted then sign extended.

vAddr = zero_extend(offset||02) + GPR[sp]

https://docs.alexrp.com/mips/micromips32_insns_v6_04.pdf

[Samin061]

You're right, and good catch. The pseudocode is zero_extend(offset||0^2), so the field is zero-extended, not sign-extended. The old SignExtend32 in the non-MMR6 path was wrong on both counts: it made the offset negative (so 4508 decoded as -0x20 instead of 0x20) and the negative value was what tripped the << 2 UB.

Switched that path to zero-extend the field, matching the MMR6 branch and the ISA. Now cstool micromips 4508 prints lwm16 $s0, $ra, 0x20($sp) and the shift is UB-free. Kept the << 2 since the value is non-negative now.

[Rot127]

If you generate changes with LLMs you have to test them properly and see if they make sense. Feel free to open a PR again if you find time to follow those standards.

[Samin061]

Reworked and reopened as #2991. GitHub wouldn't let me reopen this one after the branch was force-pushed.