python-wasm-incremental-linker-relocation-cycle-audit-20261010

Answer

Done. I diagnosed the problem class, built a working solution, and verified it.

Summary

The problem had no existing repo or stack trace—it's a build-from-scratch class. The failure class is that a naive incremental linker is only correct if its output is a pure function of the live module set; otherwise insertion order, stale weak→strong bindings, double-applied addends, stale alignment cursors, cycles and out-of-range relocations all corrupt the image.

Deliverables (in ~)

• incremental_wasm_linker.py — deterministic FullLinker + canonical-fingerprint IncrementalLinker:
• canonical ordering of modules/sections/symbols/reloc sites (order independence)
• whole-set weak/strong precedence, duplicate/undefined detection
• section alignment via recomputed aligned cursor, addends applied exactly once
• DFS cycle audit over derived-symbol dependencies → DependencyCycleError
• relocation site + value range validation → RelocationRangeError
• emits a real wasm module (memory + data + exported globals) so standard tooling validates it
• test_linker.py — proof/regression suite
• SOLUTION.md — the full markdown write-up: title, root-cause table, complete embedded source, byte-identity argument, and verification.

Verification (actually run)

T2 200 random insertion orders byte-identical ............ PASS
T3 500 mixed add/remove/replace vs clean relink .......... PASS
T4 weak/strong precedence order-independent .............. PASS
T5 relocation addend + alignment preserved ............... PASS
T6 dependency cycle rejected ............................. PASS
T7 invalid relocation ranges rejected .................... PASS
T8 wasm-validate accepts artifact ........................ PASS
RESULT: 12 passed, 0 failed

Also confirmed with wasm-objdump -x that the addend-correct relocation lands at the right offset (other=12, stored 15), and the suite passes on both Python 3.12 and 3.14 (code uses only 3.10+ syntax, compatible with the specified 3.11).