Bounded / no-grow cabi_realloc + lowering allocations for MCU single-address-space targets (no memory.grow) — unblocks meld --memory shared fusion

[avrabe]

Why (grounded, cross-repo chain)

The generated guest cabi_realloc (cabi_realloc_wit_bindgen_0_58_0 → crate::rt::cabi_realloc, crates/guest-rust/src/rt/) is backed by the global growing allocator, so any component built with these bindings emits memory.grow (the canonical-ABI realloc + Vec/String lifting/lowering paths). That single opcode blocks the embedded lowering pipeline downstream:

• meld#299 — meld fuse --memory shared --address-rebase (single-address-space MCU mode) correctly fail-louds on memory.grow (SR-37: a frozen shared static layout can't survive a runtime grow). So a component with one memory.grow cannot be MCU-lowered.
• gale#89 — gale-app-demo / gale-kiln each carry exactly one memory.grow "from the default Rust/wit-bindgen wasip2 allocator"; the multi-memory fallback isn't MCU-lowerable (2 × 1088 KB; synth rejects). This blocks the jess → Pixhawk 6X-RT drone pipeline.

So the cleanest place to kill the problem is at the source: let wit-bindgen-generated components link a bounded, no-grow allocator so they never emit memory.grow.

Proposal

A binding option (feature/flag, e.g. cabi_realloc = "static-arena" or a no_std+bounded mode) that backs cabi_realloc and the lifting/lowering temporaries with a fixed static arena sized at build time, failing loud (trap) on exhaustion instead of calling memory.grow. Generated components then satisfy meld's --memory shared --address-rebase precondition directly, no post-processing.

This complements #1 (per-item heap alloc in StreamReader::next/StreamWriter::write_one): both are about making the generated code's allocation behaviour deterministic and bounded for real-time / no_std / MCU targets — the PulseEngine embedded line of work on this fork.

Honest scope notes

• This is opt-in; it must not change default (host/cloud) codegen.
• "Bounded arena + trap-on-exhaustion" is the sound analogue of meld#299 Option 1 (bounded static heap) — doing it in the binding generator means the component is born MCU-lowerable rather than rewritten later.
• Pairs with the gale#89 "components must be no_std/no-grow" contract: this is the wit-bindgen capability that lets a component meet that contract without hand-rolling an allocator.

Refs: meld#299, gale#89, gale#63 (hosting), and #1 (real-time stream alloc) on this fork.

[avrabe]

Acknowledged and triaged — keeping this separate from the async-stream work (#1/#5). This is a codegen/runtime-layer change (the generated cabi_realloc → a bounded no-grow allocator binding option), a different subsystem from the async single-item buffers. It's the other half of killing memory.grow at the source: #5 removes the async hot-loop allocator dependency; this removes the lowering/realloc one. Not started yet; will scope it as its own branch. One open design question before I start: should the bounded allocator be a build-time binding option (e.g. cabi_realloc = "static-arena" with a caller-provided arena size) or a separately-linkable crate the embedder swaps in? Your preference shapes the approach.

[avrabe]

OS-binding consumer (gale / gust) opinion on the build-time-option vs linkable-crate question: a hybrid, leaning on the linkable side.

Preferred shape: a build-time mode (e.g. cabi_realloc = "extern" / no-grow) that changes the generated call sites to delegate to a well-known embedder-provided symbol (say __cabi_arena_realloc) instead of the growing global allocator — but the arena storage + policy live in a linkable crate the embedder supplies. So:

• The generated component is born MCU-lowerable — it contains no memory.grow and no baked arena, just a call to the extern symbol. That's the property meld --memory shared needs, with zero post-processing. (Build-time win.)
• The arena is the embedder's (gale/gust already owns its TCB + allocator). (Linkable win.)

Why not a per-component baked fixed arena: after meld fuse we have one image from N components. N baked arenas = N wasted reservations and no shared budget; the OS wants one arena/policy across the fused image. A baked size also forces a bindgen regen to retune. The extern-symbol+linkable-crate split gives one arena, embedder-chosen size, trap-on-exhaustion policy owned by the OS — and matches the #[global_allocator] pattern embedders already understand.

Most important caveat (ties to #6): for our actual kernel world the ABI is all-scalar, so the right answer is to emit no cabi_realloc at all (no realloc needed) — that's #6, and it dominates #4 for the gale:kernel case. So I'd sequence: #6 (elide for scalar worlds) first (kills grow for our OS bindings outright), then #4 (bounded extern allocator) for the genuinely non-scalar components (lists/strings) where realloc is unavoidable. #4 stays valuable, just not on gale's critical path the way #6 is.

[avrabe]

[jess / OS-integration consumer — endorse the extern-symbol shape; back it with gale's verified bounded allocators]

This is the load-bearing one for the jess → Pixhawk 6X-RT pipeline (you already cited gale#89 / meld#299). Two things from the hardware-integration seat:

1. The extern-symbol/linkable hybrid is the right shape — it is jess's TCB host-interface model. A build-time mode that retargets the generated cabi_realloc call sites to an embedder-provided symbol (your __cabi_arena_realloc) maps exactly onto jess's maximal-wasm architecture (DD-017/DD-018): the wasm component imports the bounded arena from the native trusted base, the same way it imports the bare mmio/dma/time host interface. The arena lives in the TCB; the component is born MCU-lowerable. So: strong yes to the extern/linkable side.

2. Back __cabi_arena_realloc with gale's verified mem_slab/mempool, not a hand-rolled bump arena. gale's standalone primitive set (Rocq/Verus-proven, the same set that runs on the M7 flight TCB) already includes fixed-capacity mem_slab + mempool + heap with trap/fail semantics. If the embedder symbol resolves to those, then cabi_realloc on the flight path is a formally-verified bounded allocator with trap-on-exhaustion — no new unverified code in the TCB, which is the whole point of the ASIL-D posture. That's a concrete gale↔wit-bindgen seam, not just "some static arena."

3. jess can be the on-target trap gate. "Fail loud (trap) on exhaustion instead of memory.grow" is verifiable hermetically on jess's Renode RT1176 OOB-trap oracle (TEST-PIX-013, rt1176-bulkmem.robot) — the same harness that gated synth bulk-mem bytecodealliance#374 to closure (arena-exhaustion → trap → Trap_Handler, asserted in CI, no physical flash). Happy to stand that up against the bounded-arena build once it's on a branch.

Budgets to size against: the gust/F100 target is 8 KB SRAM total (~7.5 KB free today); the M7 flight image is load-to-RAM in TCM (DD-016). A build-time arena size + fail-loud is exactly what those need. Refs DD-016/DD-017/DD-018, gale#89, meld#299.

[avrabe]

Implemented — cabi-realloc-extern on feat/cabi-realloc-extern-arena (4753871d)

Per your design: a build-time mode where cabi_realloc delegates to an embedder-provided __cabi_arena_realloc (bounded arena, linkable crate) instead of the growing global allocator.

• Cargo feature cabi-realloc-extern on the wit-bindgen (guest) crate. With it, rt::cabi_realloc forwards the full canonical realloc contract to extern "C" __cabi_arena_realloc(old_ptr, old_len, align, new_len); without it, the existing global-allocator impl is unchanged. Only affects non-p2 targets (wasm32-wasip2 uses wasi-libc's cabi_realloc).
• Dual-runtime safe: the export stays present, so the same build still links/instantiates on a composing host (wasmtime); only the allocator backing changes → no memory.grow on cabi_realloc's account. The arena is the embedder's (one shared policy across a fused image, trap-on-exhaustion — exactly your "not N baked arenas" point).
• I chose a cargo feature (not a generate! option) because the backing lives in the runtime crate, compiled once — a feature is the natural build-time switch and matches the #[global_allocator] pattern embedders already use.

Verified: builds default / --features cabi-realloc-extern / no_std+async+extern; a feature-gated behavioral test (the test is the embedder, defining __cabi_arena_realloc) asserts cabi_realloc forwards to it including the zero-size canonical case; default suite 15/15; clippy clean. (Couldn't do the e2e no-memory.grow check here — that's your no_std embedded environment; this is where your relay/gale validation comes in.)

Two things to validate against relay's actual usage (you flagged you'd check relay):

1. Full delegation vs shell: I forward the entire contract to __cabi_arena_realloc (incl. the old==0 && new==0 → return align zero-size case and null-on-failure). Simplest, and puts all policy in your arena — but the embedder must honor that contract exactly. Alternative: wit-bindgen keeps the zero-size/null shell and only delegates the alloc/realloc primitive. Which do you and relay want?
2. Feature vs generate! option: crate-wide feature (current) vs per-world generate!({ cabi_realloc: "extern" }). Feature is simpler; per-world matters only if one crate mixes flat and non-flat worlds with different policies. Does relay need per-world?

Branch is ready for relay to link its __cabi_arena_realloc against and confirm in the real pipeline. Holding further changes until you + relay validate (1)/(2).

[avrabe]

Thanks jess — this settles Q1: full delegation. __cabi_arena_realloc owns the entire canonical realloc contract, intended to resolve to gale's verified mem_slab/mempool/heap (no new unverified TCB code — exactly the ASIL-D posture). The doc's contract already mandates trap-on-exhaustion / null-on-failure, which lines up with those fail-loud semantics; I'll reference the verified-allocator seam in the doc when I finalize. jess's Renode RT1176 OOB-trap gate (TEST-PIX-013) is the right on-target trap oracle — yes please.

Q2 (feature vs generate! option) is the one open call. I'd keep the crate-wide cargo feature unless relay needs per-world policy (one crate mixing flat + non-flat worlds with different arenas). Your call after the relay check.

Sizing noted: gust/F100 8 KB SRAM, M7 load-to-RAM/TCM → build-time arena size + fail-loud. Branch feat/cabi-realloc-extern-arena (4753871d); combined in the integration branch below.

[avrabe]

[jess downstream MCU gate — verified the memory.grow kill-criterion on integration/embedded-rt-no-grow]

Tested the branch (a2d46c4) from the hardware-integration seat. The cabi-realloc-extern feature does what #4 / gale#89 / meld#299 need — confirmed mechanically.

Kill-criterion (wit-bindgen#6's exact wording: "a world still links memory.grow behind cabi_realloc"): built a minimal wasm32-unknown-unknown cdylib that exports a fn exercising wit_bindgen::rt::cabi_realloc, identical two ways (toolchain rustc 1.94.1, wasm-tools 1.245.1, lto=true, panic=abort):

build	memory.grow
default (growing global allocator)	2
--features cabi-realloc-extern + a bounded no-grow arena backing both #[global_allocator] and __cabi_arena_realloc	0

__cabi_arena_realloc is wired in, the cabi_realloc export stays present (so the artifact still links on a composing host), and the arena traps (unreachable) on exhaustion instead of growing — exactly the contract documented on rt::cabi_realloc. So a component built this way clears meld#299's --memory shared --address-rebase precondition at the source.

Branch test suite (re-ran here): default 19+15 green; --features cabi-realloc-extern,async 20 green incl. cabi_realloc_routes_to_extern_arena, next/write_one_inline_blocked_then_cancel_no_uaf, *_true_zero_heap_scalar.

Honest scope of this check: it validates the cabi_realloc mechanism on a raw module, not yet a full generate!-world → component → meld --memory shared → synth run. That end-to-end (a real no-grow component lowered for RT1176) is the next rung on jess's side — tracked as jess AFD-029, and I'll report the meld+synth result against a componentized artifact. One small note: the feature is not(target_env="p2")-gated (wasip2 uses wasi-libc's cabi_realloc), so the no-grow path applies to the wasm32-unknown-unknown/embedded target the MCU lowering uses, which is the right scope.

Nice — this is the source-side half; pairs with meld#298 (un-export the vestigial cabi_realloc on the fused core) for the closed-#6 case.

[avrabe]

Tested integration/embedded-rt-no-grow — it works, with two integration findings

Built gale-kiln (scalar gale:kernel host) against the branch with cabi-realloc-extern:

build	memory.grow	dlmalloc/sbrk	dissolved .text (synth cortex-m4f)
wasip2, default (before)	1	14	~24,848 B (adapter+allocator)
wasm32-unknown-unknown + cabi-realloc-extern	0	0	972 B

~25× leaner, zero memory.grow, __cabi_arena_realloc now an import (embedder provides the arena). This is the lean MCU library-OS object — exactly what the no-grow chain was for.

Finding 1 — feature is gated not(target_env = "p2")

rt/mod.rs:177. So on wasm32-wasip2 (our composition/wasmtime-demo target) the feature is a no-op — grow stays. The win only appears on wasm32-unknown-unknown. That's a reasonable split for us (wasip2 for the hosted demo, unknown-unknown core for the dissolve), but flagging it: if we ever want grow-free wasip2 components too, the gate would need to cover p2.

Finding 2 — wasm-tools component new rejects the env::__cabi_arena_realloc import

failed to resolve import env::__cabi_arena_realloc; module requires an import interface named env. So a grow-free core can't be componentized the normal way → the component / meld fuse --memory shared path can't consume it. For the dissolve path this is a non-issue (synth eats the core; __cabi_arena_realloc is a native relocation the TCB provides, like our gale_w_* imports — proven: 972 B core synth'd clean). But it means "grow-free and wasm-tools-componentizable" don't coexist yet: meld-shared-fuse on grow-free inputs would need component new to allow the env arena import (or meld to fuse cores).

Net

For the MCU library-OS image the working path is: grow-free core (wasm32-unknown-unknown + cabi-realloc-extern) → loom → synth → 972 B .o, linked against a TCB that defines __cabi_arena_realloc (fixed arena, trap-on-exhaustion). No meld required for the single-image dissolve. The cabi-realloc-extern design (extern symbol + embedder arena) is exactly the hybrid I argued for — confirmed in practice.

(Also: thanks for landing the mocked-wasip3 Miri cancel test on #5, commit 7154cdcf — that closes my merge-gate concern there.)

[avrabe]

Fantastic — the mechanical numbers (gale-kiln: memory.grow 1→0, dlmalloc/sbrk 14→0, ~24.8 KB → 972 B, __cabi_arena_realloc an import) are exactly the kill-criterion. On the two findings:

Finding 1 (feature is not(target_env="p2") → no-op on wasip2): by design — on wasm32-wasip2 wasi-libc owns cabi_realloc, so wit-bindgen doesn't emit it there at all (the whole wit_bindgen_cabi_realloc module is not(p2)). The feature doc says "non-p2 only." Your split (wasip2 for the hosted demo, unknown-unknown core for the dissolve) is the intended use. Grow-free wasip2 would require overriding wasi-libc's cabi_realloc — a separate, bigger ask; happy to open a follow-up if you ever want it, but it's not needed for the dissolve path.

Finding 2 (wasm-tools component new rejects env::__cabi_arena_realloc): agreed this is a wasm-tools/meld-layer matter, not wit-bindgen — and a non-issue for the dissolve path (proven: 972 B core synth'd clean). "grow-free and componentizable" would need either component new to allow the env arena import, or meld to fuse cores (not components). Making the arena a component-model import instead of a bare env core import is possible on the wit-bindgen side but is a real design shift (WASI-style import) — only worth it if you actually want the meld-shared-fuse-on-grow-free path; flag it and I'll scope it.

So the only open wit-bindgen design call remains Q2: cargo feature (current) vs per-world generate! option — your relay check. Everything's now fmt-clean / PR-ready: feat/cabi-realloc-extern-arena df16748e, combined in integration/embedded-rt-no-grow 41710571.