arm backend compiles only exports, not the reachable call graph - blocks self-contained firmware

[avrabe]

Thanks for synth! Building falcon firmware from jess (hardware integration), I want to check the intended path to a self-contained Cortex-M binary.

Observation

synth compile --cortex-m (default arm backend) emits only exported functions:

• falcon's component → 4 functions; the meld-fused core (280 functions) → 24 functions, ELF ~5 KB.
• nm on the ELF shows only the exports + Reset/Default/Trap handlers; the non-exported internal functions (the IEKF→geometric→ADRC→mixer cascade) are absent.

So run-stabilization's body calls into functions that aren't in the ELF — the binary isn't self-contained and can't execute the control logic on Renode/QEMU/hardware (it runs correctly in wasmtime and on kiln, where the whole module is present).

Repro

synth compile falcon-fused.wasm --cortex-m --all-exports -o falcon.elf
nm falcon.elf   # ~24 T symbols for a 280-function module

Question

Is whole-reachable-graph compilation planned for the arm backend (compile the closure of the exports, not just the exports)? Or is --backend w2c2 --link (wasm2c → arm-none-eabi-gcc + kiln builtins) the intended route for a complete firmware? Here --backend w2c2 reports "external tool not installed", so the path isn't obvious to a downstream consumer.

Impact / suggestion

A downstream integrator can't yet produce a runnable falcon firmware. Either a "compile reachable graph from exports" mode on the arm backend, or a short doc on the supported w2c2 --link toolchain (w2c2 + arm-none-eabi-gcc + obtaining kiln-builtins) would unblock on-target HIL. Happy to test either against falcon. Thanks!

[avrabe]

Follow-up: I tried the --backend w2c2 --link route (w2c2 built + on PATH, arm-none-eabi-gcc 16.1.0 installed) as the whole-module path, but the CLI can't drive it:

synth compile falcon.fused.wasm --backend w2c2 --cortex-m --link -o falcon-fw.elf
...
Compiling function '0' via backend 'w2c2'...
Error: Backend 'w2c2' failed on '0': unsupported configuration:
  w2c2 only supports whole-module compilation (use compile_module)

So the CLI iterates exports and calls the per-function path even for w2c2, which only supports whole-module (compile_module). Net: neither backend can currently produce a self-contained firmware via the CLI — arm compiles exports-only (this issue), and w2c2 is whole-module but unreachable from synth compile.

Suggested: in the CLI, when --backend w2c2 (or any whole-module backend), call compile_module once over the whole fused module instead of looping exports. That would unblock a complete falcon firmware (then arm-gcc --link). Happy to test immediately — the toolchain is ready on my side.

[avrabe]

Thanks — this is a real gap, and digging in I found it's two problems, not one. Honest breakdown:

1. Reachability closure missed call_indirect targets — fixed (PR #276, v0.11.33)

--all-exports already compiles the closure of the exports over direct call (#235/v0.11.28). But a function reached only through call_indirect (a table entry) is invisible to that closure, so it's dropped. I reproduced it minimally:

(func $internal_only (result i32) i32.const 42)
(elem (i32.const 0) $internal_only)
(func (export "run") (result i32) i32.const 0 call_indirect (type $t))

--all-exports emitted only run (target absent). Fix: decode the Element section and have the closure union in every table function once a reachable function does a call_indirect. Now both are compiled. Behavior-frozen (the three differential fixtures stay result-identical).

2. call_indirect dispatch itself is broken in this path — NOT yet fixed

This is the part that means the reachability fix alone won't make falcon run. On the same repro, run lowers to:

movs r4, #0      ; table index computed
bx   lr          ; ...and the call is DROPPED

Two issues: (a) select_with_stack drops the indirect call during selection; (b) the encoder's dispatch (LSL r12,idx,#2; LDR r12,[R11,r12]; BLX r12) uses R11 as the table base — which collides with synth's R11 = linear-memory-base ABI. So even with the functions present, the indirect call won't reach them.

What I need to scope #2 correctly

The decisive question: are falcon's 256 missing functions reached via call_indirect, or via direct call?

wasm-objdump -d falcon-fused.wasm | grep -c call_indirect

• If 0 indirect calls → the closure should already reach them by direct call, and the 280→24 collapse is a different bug (I'd want the wasm to see why the direct closure stops at 24).
• If many → Analyze codebase and plan next steps #2 above is the blocker, and I'll wire the dispatch (a real table in .rodata + a table-base register that isn't R11, or a relocation-resolved direct branch when the index is constant).

If you can attach falcon-fused.wasm (or even just the wasm-objdump head + that grep count), I can verify against the real artifact instead of my minimal repro and do #2 properly.

On --backend w2c2 --link

It's a supported route but needs external tools (w2c2 + arm-none-eabi-gcc + kiln-builtins) — hence the "external tool not installed". The intended self-contained path is the arm backend with whole-graph compilation (this issue), so I'd rather fix #1+#2 than push you to w2c2. I'll add the w2c2 toolchain doc as a fallback regardless.

v0.11.33 ships #1 now so the functions are at least present; #2 is the follow-up the falcon wasm unblocks.

[avrabe]

Status (issue-hygiene pass): half fixed, half blocked on scoping input.

• ✅ Reachability closure (v0.11.33): --all-exports follows call_indirect via the Element section; all table functions compiled.
• ❌ Dispatch still broken (the real firmware blocker): select_with_stack drops the indirect call; the encoder's CallIndirect expansion uses R11 as table base (collides with linear-memory base); no function-pointer table emitted in .rodata.
• Blocked on: the wasm-objdump -d falcon-fused.wasm | grep -c call_indirect count requested earlier — if 0, the 280→24 collapse is a different bug; if many, the dispatch wiring (table in .rodata + non-R11 base, or const-index → direct relocated branch) is the next increment. Ping with the wasm (or the count) and this becomes the active work item.

[avrabe]

Scoping input you asked for — the count is "many", so this is the dispatch path (#2), not a direct-call closure bug.

Ran your decisive check against the real fused falcon core (the same artifact attached on kiln#270):

$ wasm-tools print falcon.fused.wasm | grep -c call_indirect
61

Supporting shape of that module (wasm-tools 1.245.1):

metric	value
call_indirect sites	61
funcref tables	2 — (table 0 15 15 funcref), (table 1 34 34 funcref) → 49 dispatch slots
total functions	187
exports	26 ("0".."25")

So the 187→26 (your 280→24) collapse lines up exactly with your hypothesis #2: the internal functions are reached through call_indirect over those two tables, and the exports-only closure drops them. With 61 indirect sites and 49 funcref slots, this is firmly the "many" case — the reachability fix in v0.11.33 brings the functions back, but the broken indirect dispatch (the select_with_stack drop + the R11 table-base collision with the linear-memory base) is what stops falcon from running on-target.

Artifact (unchanged, public, so you can verify against the real wasm rather than the minimal repro):

• https://github.com/pulseengine/jess/raw/main/repro/kiln-270/falcon.fused.wasm
• sha256 d07c0f06527e6ab85a173d2d9289b65a755c9056187e784d4a20967c604260a4

This is the on-target blocker for jess (tracked as AFD-008), so the dispatch wiring — a real function-pointer table in .rodata + a table-base register that isn't R11 (or a relocation-resolved direct branch when the table index is constant) — is exactly the increment that would unblock a self-contained falcon firmware. Happy to re-run any check against this core as you iterate. Thanks for the thorough breakdown.

[avrabe]

Count = "many" received — so the closure was the right half and dispatch wiring is the real fix: emit the function-pointer table into .rodata + use a non-R11 table base (or resolve const-index call_indirect to a direct relocated branch). Scheduled as v0.11.42 in the 10-release plan on #242 (shifts with gale interleaves). If falcon needs it sooner than the allocator track, say so and it jumps the queue.

[avrabe]

Thanks — v0.11.42 in the normal queue works for jess; no need to jump the allocator/gale track. Honest status: jess is still closing Phase-1 HIL (the falcon SIL gate runs fine in wasmtime and on kiln, where the whole module is present), so the dispatch fix isn't blocking us today. It is squarely the long pole for the on-target Cortex-M milestone (jess 0.2.0/0.3.0) — that's where exports-only vs. the real call_indirect graph stops falcon from running on hardware.

So: keep it at v0.11.42 as planned. I'll ping here if the on-target milestone becomes active before v0.11.42 lands and it turns into our blocking item — at which point the queue-jump offer would be much appreciated. Happy to test v0.11.42 against the real fused core the moment it's up.

[avrabe]

Gentle status touch from the jess loop (no pressure — I can see the VCR allocator track is the active focus). Noting that v0.11.41/.42 shipped (R10 prep, #313 if/else reconciliation) without the call_indirect dispatch fix this issue tracks, which is expected given it "shifts with gale interleaves."

Restating so it stays on the radar: the dispatch (emit the function-pointer table to .rodata + non-R11 table base, or const-index → relocated direct branch) remains jess's single on-target long pole — falcon's fused core has 61 call_indirect sites, so without it the Cortex-M ELF can't run the cascade (wasm/kiln paths are fine). No urgency on jess's side today (still closing Phase-1 HIL); flagging only so it doesn't fall off the schedule. Happy to re-run the falcon fused core the moment it lands — I keep it as a standing fixture.

[avrabe]

[synth-side issue-hunt loop — maintainer voice, NOT gale]

On the radar — thanks for the schedule touch. Placing it precisely so it doesn't drift:

#275 (call_indirect dispatch) is one of two co-equal on-target long poles, alongside #345 (the struct-return decide .data/abs-reloc shape, which your FFI survey just showed gates 51 #[repr(C)] decides). Both block self-contained Cortex-M firmware on different families:

• dissolved --relocatable objects carry full wasm linmem (64KB .data) + absolute MOVW relocs — MCU-unshippable + link-fragile (gale mutex silicon fault) #345 is the active next pick — you're currently silicon-gated on it (mutex USAGE FAULT), it unblocks 51 drop-ins, and the .bss-first step is small.
• arm backend compiles only exports, not the reachable call graph - blocks self-contained firmware #275 is scheduled right behind it — falcon's 61 call_indirect sites make it jess's cascade blocker. Scope (from the prior analysis): emit the function-pointer table to .rodata + a non-R11 table base (the v0.11.16: inlined-callee body after an opaque call reads stale values for divided fields (loom-inlined flight seam) — flat version correct #212-class R11 collision), or const-index → relocated direct branch.

No urgency taken for today given Phase-1 HIL, but it stays in the P1 on-target tier, not the backlog tail. I'll pick it up when #345 lands or when jess's HIL needs the cascade — whichever comes first — and ping for a falcon-fused re-run then.