TextureSequence::Prepare and MaterialChanger::Prepare are static

[andrewboudreau]

TextureSequence::Prepare and MaterialChanger::Prepare were declared as ordinary members and defined as forwarding (this, &model, &file). They take two arguments and no this.

Why the wrong reading survived

Both ROM bodies are 0xc long-call veneers — ldr ip,[pc]; bx ip; .word <impl>. A pure tail jump reproduces under any signature, so the definition files never constrained the question. The constraint lives on the two sides nobody had consulted:

The callee. func_02046d50 and func_020470e8 read only r0 and r1:

push {r4-r7,lr} / sub sp,sp,#4
mov  r6, r1      <- ldrh [r6,#2], ldr [r6,#4], ldrh [r6,#8],
mov  r7, r0         ldr [r6,#0xc], ldrh [r6,#0x1c], ldr [r6,#0x20]

r2 is never touched, which rules out a third argument. And the offsets r1 is read at are exactly BTP_File's declared fields — so r1 is the animation file, the second argument. Under the old reading it would have been the BMD.

The callers. Every call site in the tree passes two. So do both matched implementations, src/func_02046d50.c and src/func_020470e8.c.

A static member mangles identically, so no symbol changes and no config moves.

TextureTransformer, the third sibling, was corrected long ago. Its header already names these two veneers as "called the same way" and notes the old reading "cost the PC port a wrong-register hunt" — the follow-up just never happened. This is it.

What changed

Twenty-two call sites drop the mangled extern for TextureSequence::Prepare(model, file). The six .c callers keep theirs — C has no ::.

SnowmanHead and InvisibleSecret declare the class locally rather than including TextureSequence.h: both carry typedef int Fix12;, which collides with the real math/Fix12.h template.

Several of the removed externs were a bare extern on an already-mangled name inside a //cpp file, which mangles a second time. That shows up in the one gate that can see it: _Z49_ZN15TextureSequence7PrepareER8BMD_FileR8BTP_Fileii leaves the unresolved backlog. Eyerok's linkcheck improves BLIND-39 -> BLIND-35 as four call destinations become resolvable.

The other three commits

Whomp's MeshColliderBase address was double-mangled. Found while running the gates, in a file this change already touches. The declaration sat outside the extern "C" block above it, so the address taken pointed at a _Z88_ZN16... that does not exist. The byte gate cannot see this — relocated words are wildcards. Linkcheck goes BLIND-1 -> VERIFIED and the function still reproduces.

The unresolved-reference baseline is re-pinned to main. config/unresolved-baseline.json had drifted: it recorded 10805 eligible against main's 10813, and check_references fails on clean origin/main with no feature branch involved:

git checkout origin/main
python tools/eligible.py
python tools/check_references.py            # FAIL
python tools/check_references.py --update
# refusing to update: symbols left the backlog by failing differently

The ratchet could not unstick itself. --update refuses, correctly, because one symbol left the backlog without being fixed: func_ov091_021339fc was deliberately converted to a hand-written asm hatch by an earlier merged PR, which takes it out of eligible.py's candidate set. It did not degrade, it was reclassified — and the reason-switching guard cannot tell those apart, which is exactly why unsticking it has to be a deliberate decision rather than a --update.

The other two entries are main's as well, and neither has a correct fix:

• func_02057410 references _ll_udiv / _ull_mod, mwccarm's names for the 64-bit division helpers it emits for the (u64)v / (u64)pf[1] at func_02057410.c:304. The ROM's implementations are __aeabi_uldiv / __aeabi_ulmod in ITCM (0x01ffa9dc, 0x01ffa9e8), but check_references has no alias mechanism, and adding _ll_udiv as a second symbol at that address would create the duplicate-address condition that makes CI report lost matched functions.
• Whomp::InitResources references func_021135d4, which dsd resolves to module:overlays(9,14,15,16,18,19,20,22,24,25,26,27,29,32,36). All fifteen load at 0x021111a0, so that one instruction targets different data depending on the level and no single name is correct.

The baseline was generated on a clean origin/main checkout, so it carries nothing from this branch. Verify by checking out origin/main, running tools/eligible.py, and regenerating — the result is byte-identical.

Then two fixes are banked back down with --update, which is downward-only: the two double-mangled names above leave the backlog, nothing is added, and the ratchet now refuses to let either come back.

Gates

• rombuild 106/106 exact, 10,813 reproducing, 0 mismatching
• eligible name list byte-identical to main at 10813
• check_references OK: no new unresolvable references (pre-push hook passes; no --no-verify)
• prepush_linkcheck 23 checked, 21 verified, 0 blocking
• prepush_attribution 0 changed / 0 lost · port_refcheck 393 resolve · header offsets, data definitions, duplicate sources clean

Not fixed, stated plainly

Goomba::InitResources and MrI::InitResources do not reproduce — before or after. Both fail identically on origin/main (999 and 7 words), and their compiled bytes are unchanged by this branch: 916 → 916 and 664 → 664, identical in both cases. So the edits there are provably neutral, not merely still-failing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XxDmkQ47fWa3GB6mj8xEQe

[tangos-validator]

⚠️ PR validation — Error

worker error: pr_linkcheck exited 1 without a report: (1 slot(s))
ok src/_ZN3Amp8BehaviorEv.cpp (1 slot(s))
Traceback (most recent call last):
File "/home/validator/clone/tools/pr_linkcheck.py", line 418, in
main()
File "/home/validator/clone/tools/pr_linkcheck.py", line 342, in main
if w == "NO-REPRO" and asm_policy.has_draft_banner(text):
^^^^^^^^^^
NameError: name 'asm_policy' is not defined

_{Each changed src/*.c|*.cpp is compiled and its relocated bytes compared to the binary data on a private build box. Passing requires every changed file to reproduce the ROM byte-for-byte with correct relocation targets — this catches WRONG-DEST relocations and non-reproducing near-misses that ledger-scoped linkcheck skips.}