Following e1482ab I disassembled the function supplying r2 and made two errors,
both mine. First I read the jal target as 0x2ee178 when it is 0x2ee138 --
0x0bb84e << 2 is 3,072,312. Second, at the correct address the bytes do not
decode: d8a10000 is opcode 0x36, which is not a valid MIPS major opcode for
user-space code. The coherent readings are that this is data, that the decomp's
extent is mis-bounded, or that the jal target is still wrong.
Stopping here deliberately. An un-masked branch target that reported a false
negative, and a transposed address that produced plausible-looking garbage, are
enough to make anything else from this decoder untrustworthy. The next step is not
another immediate scan or another hand-decoded disassembly -- it is
tools/overlay-anchors, which links capstone, verified against a known-good
function first.
The established chain, with nothing inferred beyond it:
0x3a3d70 jal 0x2ee138 target decoded, callee unidentified
0x3a3d84 jal 0x3a7c30 r2 = return value of the above
0x3a7c30 580 bytes, never writes r2
0x3a7d88 jal 0x3a8060 passes r2 through
0x3a8060 addiu r17, r18, 0xc0 with 0xd0 and 0xe0; 16-byte-stride walk
What 0x2ee138 returns is unknown, and it is the single remaining link between the
program and moby_classes.offset.
284 passing with the disc present, clippy clean.
ReaperOfVeriod
d97e7df41f