fuzz: i64_lowering_doesnt_clobber_params flags Mov R0,R8 as AAPCS clobber — real clobber or harness false-positive?

[avrabe]

Summary

Separate from #186 (which fixed encoder_no_panic totality), the i64_lowering_doesnt_clobber_params fuzz target reports an AAPCS clobber in select_with_stack i64 lowering. Pre-existing on main (the lowering path is untouched by the #180/#184/#186 encoder work).

Reproducer

Crash input (Base64): AAUx1/fX19fX19fX19fX19fX1w==

assertion left != right failed: AAPCS clobber: ARM instr at wasm line 3 writes
param reg R0 before LocalGet(0) at line 5. Op: Mov { rd: R0, op2: Reg(R8) }.
Sequence:
  Push { R4,R5,R6,R7,R8,LR }
  I64Const { rdlo: R4, rdhi: R5, value: 0 }
  Mov R6, R4
  Movw R7, 0
  Mov R8, R6
  Movw R12, 0
  Mov R0, R8          <-- flagged: writes param R0
  Movw R1, 0
  Pop { R4,R5,R6,R7,R8,PC }

The open question: real clobber or harness false-positive?

The flagged Mov R0, R8 is the return-value placement (R0:R1 = the i64 low:high), at the function epilogue right before Pop. The lowered sequence contains no LocalGet(0) read after it — so the param-0 value, if ever read, is read earlier. The harness (i64_lowering_doesnt_clobber_params.rs:163) flags it because it tracks "first LocalGet(p) at wasm line 5" but the ARM for that LocalGet may be dead/elided (its value dropped), in which case overwriting R0 for the return is legitimate and this is a false-positive in the harness's first-read model.

Done when

• Determine real-vs-false-positive by reconstructing the wasm from the input and tracing whether LocalGet(0)'s value is live.
• If real: fix the i64 lowering to not place the return value in R0 before a live param read (the I64SetCond hardcodes R0..R3, clobbers param registers (found by #100 fuzz harness) #103/fix(opt): systematic AAPCS-clobber audit — sweep all hardcoded R0..R3 usages #108 AAPCS-clobber class).
• If false-positive: tighten the harness carve-out (it already has dead-store carve-outs at lines 130-160) to also skip return-placement writes when the protected LocalGet's result is dead, and add this input as a seed.
• Either way: add a committed fuzz/seed_corpus/i64_lowering_doesnt_clobber_params/ (the target currently has none, like encoder_no_panic did — see arm encoder: not fuzz-total — arithmetic underflows + empty seed corpus make encoder_no_panic flaky #186).

[avrabe]

Triage: at least two distinct false-positive modes — needs a liveness/validity model, not a one-line carve-out

Reconstructed both crash inputs (instrumented the harness to dump wasm_ops). Findings:

Pattern A — dead read (immediately dropped)

wasm[5] LocalGet(0)
wasm[6] Drop            ← protected read's value is dead

The harness appends LocalGet(p); Drop for every param to "force a read," but the Drop makes it dead, so the flagged Mov R0,R8 (return placement) before it is observably harmless. A naive fix — skip LocalGet(p) immediately followed by Drop — handles this case.

Pattern B — clobber on type-invalid input (breaks the naive fix immediately)

A 120s sweep with Pattern A patched crashed again within seconds:

NUM_PARAMS=2
wasm[0] I64Const(0)
wasm[1] I32Const(16777217)
wasm[2] I32Const(603979776)
wasm[3] I64Sub          ← pops two i32 (type-invalid)
wasm[4] I64Sub          ← pops i64 + nothing well-typed
wasm[5] LocalGet(1)     ← NOT Drop-adjacent (next is I32Const) → not skipped
wasm[6] I32Const(0)
wasm[7] Drop
wasm[8] LocalGet(0); Drop
wasm[10] LocalGet(1); Drop

This module is type-invalid — I64Sub popping i32 operands, unbalanced stack. A real WASM validator rejects it; synth's frontend validates before select_with_stack, so this never occurs in production. The i64-sub result landing in R0:R1 (flagged as clobbering param R1) is partly an artifact of feeding malformed ops straight to the selector.

Conclusion

The harness's first-read model has multiple false-positive modes (dead-via-Drop; type-invalid-input artifacts). A correct fix needs either:

1. Validate the constructed wasm (run it through the frontend validator) before lowering, so only well-typed modules are tested — eliminating Pattern B, or
2. A proper ARM-level liveness model (protect param p only if its LocalGet's value is actually consumed by a live observer), eliminating Pattern A.

This is deliberately not patched with a one-line carve-out: loosening a miscompilation-detector risks masking real AAPCS clobbers (the gale-critical param-passing class). It needs a considered harness redesign + adversarial verification that it still catches a genuine clobber. Leaving open for dedicated work; no rushed fix.

(Note: fuzz/ is not a published crate, so whatever the fix, it merges to main without a crates.io release.)

[avrabe]

It's a real clobber — minimal repro (not a harness false-positive)

Confirming from the consumer side (the gale wasm-cross-LTO route): a local/param that is live across a call is not preserved — the post-call code re-reads the physical register, which the callee clobbered per AAPCS. Found on synth v0.11.6 (54edb047).

Minimal repro

(module
  (memory 1)
  (func $clob (result i32) (i32.const 0))
  (func $g (export "g") (param i32) (result i32)
    (drop (call $clob))          ;; clobbers r0 (AAPCS caller-saved)
    (i32.load (local.get 0))))   ;; return *param0  — param0 must survive the call

synth compile liveacross.wat --target cortex-m4f --all-exports --relocatable -o la.o
arm-zephyr-eabi-objcopy -O binary --only-section=.text la.o la.bin
arm-zephyr-eabi-objdump -D -b binary -marm -Mforce-thumb la.bin

00000000 <g>:                   ; entry: r0 = param0
   0:  bl   clob                ; r0 := clob() return  — param0 now lost
   4:  movw ip, #0x100
   8:  movt ip, #0x2000         ; ip = 0x20000100
   c:  add  ip, ip, r0          ; r0 here = clob's return, NOT param0
  10:  ldr  r4, [ip]            ; *param0 read from (0x20000100 + clob_return) — wrong
  14:  mov  r0, r4
  16:  bx   lr

Two defects visible:

1. Live-across-call value not preserved: param0 (r0 at entry) is live into the i32.load but is never spilled to a callee-saved reg / stack across the bl clob. The load base uses the clobbered r0.
2. Wrong linmem base: 0x20000100 (= base 0x20000000 + a spurious 0x100). In the no-call case the same load lowers correctly to ldr [fp, r0] (fp = linmem base, r0 = the operand), so this only goes wrong once a value must survive a call.

Why it matters (real consumer)

This is now the blocker for compiling our hot-path kernel primitive. After #171 let z_impl_k_sem_give compile, its sem pointer param — live across k_spin_lock(...) and z_unpend_first_thread(...) — is clobbered, so sem->count/sem->limit read from 0x20000100 + <z_unpend's return>:

90: bl k_spin_lock          ; (also: lock addr 0x400 is in r5, not passed in r0)
98: bl z_unpend_first_thread ; r0 := thread
a6: add ip, ip, r0           ; r0 = thread, not sem
aa: ldr.w r8, [ip]           ; sem->count from 0x20000100 + thread  — wrong RAM

So i64_lowering_doesnt_clobber_params is catching a genuine miscompile: any value (param or local) live across a call is corrupted. The fix is to spill such values to a callee-saved register or stack slot around calls (and to use fp for the linmem base rather than materializing 0x20000100).

Environment: synth v0.11.6 (54edb047), arm backend, target cortex-m4f.