A trailing `.word 0x00000000` under a jtbl dlabel is the ORIGINAL TU's intra-rdata
.align 3 padding, NOT a table entry (0x00000000 is not a jump target). The true entry
count is the fn's `sltiu <n>` bound: func_8015AE2C has sltiu 0x7 = 7 entries yet its
raw dlabel spans 8 words.
maspsx drops all .align, so a C-emitted jump table can never reproduce the pad. Carving
to the next dlabel would reserve 8 words while the compiled object supplies 7 ->
.rodata under-fills by 4 B -> every later symbol shifts +4 (the same image-corruption
class as §41d). jtbl_range now trims trailing zero words, leaving the pad in the raw
post-carve data piece.
Retroactively explains the §8a func_80159C84 '5 words vs the real 6' false-MATCH.
Existing carves are parsed from CONFIG, not re-derived, so committed banks are
unaffected (verified: the 3 carved jtbls are absent from the raw data asm). The build
never invokes jtbl_carve, so the fleet is inert to this change until the next bank.
Found by the Fable5 crack of func_8015AE2C (562 ins x134, MATCH, pin-free).
Drew T
b0691f4bd9