Recompiler: incorrect codegen for branch-always thunks + fragment misdecode with mixed VU0/MMI

[Boodax78]

Two independent codegen issues encountered while bringing up an ELF with entry discovery enabled. Both are reproducible.

Bug 1: b target thunks do not execute target function
When a function consists only of a branch-always (b target, no link), the recompiler emits:
ctx->pc = 0xXXXXXXXXu;
return;

Example:
0x11A548: 10000012 b 0x11A594

Generated C++:
ctx->pc = 0x11A594u;
return;

Problem:
The original jal at the call site already set $ra.
The branch-only thunk should transfer control to the target while preserving $ra.
The target function must execute normally and return via its own jr $ra.

Instead, the target function never runs. The caller resumes with an unexpected ctx->pc, breaking dispatcher-style return contracts.
Expected behavior: the thunk should effectively behave as:
FUN_0011a594_0x11a594(rdram, ctx, runtime);

Manual workaround: registerFunction(thunk_addr, target_function).
This appears to be a base codegen issue for branch-always instructions, independent of entry discovery.

Bug 2: Mixed VU0 + MMI fragments misdecoded and over-sliced
Fragments discovered through the entry discovery pass that originate inside a parent function and contain both VU0 (vmove, vsub, vrinit, vrxor) and MMI instructions (pextlw, pextuw, pcpyld) are decoded incorrectly.

Observed behavior:
Instructions are misidentified (e.g. decoded as MFC1 or unrelated opcodes).
Generated fragment is not functional as generated.
Fragment boundary detection overflows into the next function in the binary.

This only occurs for fragments created by the entry discovery pass. Top-level functions decoded normally do not exhibit this issue.

These appear to be two separate root causes, bug 1 is in base codegen for branch-always instructions, bug 2 is in decode and boundary logic for mixed VU0/MMI fragment slicing.

Tested on commit 8d1f1c5

Thanks

[ran-j]

Hey thanks for the report. Can you try latest change #87

[Boodax78]

Thanks, both issues I reported are now fixed in commit 669114f

[Boodax78]

One additional issue observed after commit 669114f

A large number of recompiled functions are truncated mid-body, the generated C++ ends before the function's declared address range is complete, with no return and no jumpTarget. The last emitted C++ instruction is mid-function (e.g. addiu, sd, jal) and the remainder of the MIPS body is silently dropped.

Scope: 4360 affected functions out of ~10 700 total (~41%). Breakdown:

• 52 functions where the last MIPS instruction in range is jr $ra (opcode 0x03e00008) but the corresponding { jumpTarget ... return; } block is not emitted
• 4308 functions truncated earlier in their body (last emitted instruction is not a terminator)

At runtime this causes dispatch loops when the truncated function is used as a call target and ctx->pc is left pointing at an unregistered address.

Reproduced on commit 669114f , ELF with ~10 700 registered functions.

[ran-j]

What game are you testing?

Also try use ghidra plugin.

[Boodax78]

Testing with ICO USA (SCUS_971.13).

Using Ghidra-exported function map (official PS2Recomp Ghidra plugin CSV).
No entry discovery enabled in config.

The truncation issue reproduces consistently on commit 669114f

Approximately ~40% of generated functions are cut mid-body (no return, no jumpTarget block emitted), even though their declared address ranges from the CSV are correct.

This behavior does not appear to be caused by the Ghidra export (address ranges in the CSV are correct). It looks like a regression in the block termination or fragment slicing logic.