shared+rebase warns "UNSOUND" unconditionally — inaccurate for reloc-carrying inputs (the path pack-rebase/share-stack are built on)

[avrabe]

The problem

--memory shared --address-rebase emits an unconditional "UNSOUND" warning
(meld-core/src/lib.rs:539-549) — including for inputs that carry full
--emit-relocs metadata, where the transform is not unsound and is the path
meld's whole MCU feature line is built on.

memory strategy: explicit shared-memory + address rebasing is UNSOUND
for components that access memory via computed pointers (#326) — the
dynamic address operand of ordinary loads/stores is not rebased, so
per-component memory can silently collide. Prefer `--memory multi` ...

The warning predates the reloc consumer. Since #326→#340 shipped, a
reloc-carrying input is rebased at the source point — every reloc-flagged
i32.const address is relocated at its origin, so a pointer computed from it is
correct by construction. The blanket claim describes the pre-consumer world.

Why it matters (a safety tool crying wolf)

This warning fires on the supported, supplier-validated path:

• --pack-rebase (SR-57/--memory shared without --address-rebase merges memories but does NOT rebase — data segments silently overlap, exit 0 #370) and --share-stack (SR-66/--share-stack: collapse N duplicated shadow-stack reservations into one shared region (closes the F100 8KB gap after --pack-rebase) #380) require
  --memory shared + rebasing. The entire MCU arc runs through it.
• gale/fathom validated exactly this pipeline on real components (--memory shared without --address-rebase merges memories but does NOT rebase — data segments silently overlap, exit 0 #370): a
  provably-disjoint, executing F100 image at 51% of the SRAM budget.
• It is proven correct by an executing oracle:
  meld-core/tests/rebasing_end_to_end.rs::test_326_reloc_const_rebasing_end_to_end
  (line 454) fuses reloc-flagged inputs under SharedMemory + address_rebasing
  and asserts correct values on wasmtime (line 536).

So every gale production build prints "UNSOUND" about a transform we ship,
document, and have supplier-validated. In a functional-safety tool that is worse
than noise: it trains users to ignore warnings, including the precise one that
does matter.

The precise warning already exists

address_strategy.rs:104-115 already warns per-module, only on the no-reloc path,
naming the actual residual (#339: an absolute address used as a value, no reloc
coverage) and the remedy (--emit-relocs). And the genuinely dangerous case —
no-reloc with direct load/store — is already a hard error (path-F
MissingRelocMetadata, address_strategy.rs:87-92).

So the blanket warning is both redundant (a better-targeted one exists) and
inaccurate (it fires where the risk does not apply).

Proposal

1. Make the lib.rs warning conditional — fire only when at least one input
   lacks reloc metadata (reloc::has_reloc_metadata), or drop it entirely in
   favour of the existing per-module address_strategy warning. A fully
   reloc-covered fuse should be quiet.
2. Doc-rot: lib.rs:605 references warn_if_unsound_rebasing — no such
   function exists. Fix or remove the reference.
3. Open question (propose, don't decide): should Auto reconsider?
   resolve_auto_memory_strategy (lib.rs:553-612) never selects shared+rebase,
   citing the same stale fuse --memory auto/shared silently corrupts memory across components: load/store dynamic addresses are not rebased (no memory.grow; distinct from #172/#299) #326 rationale — even when every input carries relocs and
   nothing grows. It could plausibly select shared+rebase when all inputs are
   reloc-covered. Caveat: if any input lacks relocs and does direct memory access,
   path-F would turn a currently-working multi-memory fuse into a hard error, so
   the condition must be "all inputs reloc-covered", and ADR-4 ("explicit, not
   auto" for attested builds) argues for leaving Auto conservative regardless.
   Flagging for a decision rather than proposing the change.

Items 1–2 are small and clearly right. Item 3 is a defaults question for the
maintainer.

Not a corruption bug

To be clear about severity: this is messaging accuracy + a stale default, not
a soundness defect. Nothing is mis-compiled. The cost is warning fatigue on the
supported path and a misleading picture of what meld can do by default.

[avrabe]

Decision on item 3 (defaults): no auto-escalation — and why it's permanent

Ruled out, not deferred. Three grounded reasons, all sharpened by the
functional-safety aim:

1. The trigger would be a proxy, not a proof. reloc::has_reloc_metadata
   (reloc.rs:424-430) tests only whether a linking/reloc.* section exists.
   It does not prove every absolute address carries a reloc entry — and that
   coverage is undecidable in general (#326 Finding A: path-F gate misses absolute addresses used as values (no-reloc, no direct load/store) #339). Auto-switching on it would rest on
   a weak signal.
2. It escalates risk automatically. Multi-memory is sound for every input with
   no producer contract; shared+rebase is sound only under one. A safety tool
   should not move to the stricter-contract strategy on its own, and doing so
   would change artifact layout for existing builds (= re-verification).
3. The beneficiary population is empty. --pack-rebase, --share-stack and
   --address-rebase all already require explicit --memory shared
   (main.rs:354, 393). Every MCU/safety user is already explicit.

Shipped instead (part a, in #387): auto now reports the available build
rather than taking it — when every input is reloc-covered it names the explicit
invocation (--memory shared --address-rebase, --pack-rebase, --share-stack);
otherwise it names the missing precondition (--emit-relocs). The tool informs,
the caller chooses (ADR-4).

Correction: enforcing ADR-4 as a hard error is NOT viable as stated

The obvious complement — promote the ADR-4 attested-build warning (lib.rs:526) to
a hard error so an attested build must state --memory — cannot ship as
described. I mis-costed it. Checking the defaults:

• attestation defaults to true (lib.rs:196; CLI attestation: !no_attestation)
• --memory defaults to auto (main.rs:65)

So "attested + Auto" is not a safety-build corner — it is the default
invocation. A hard error there would make plain meld fuse a.wasm b.wasm fail
for everyone, and would contradict ADR-7's dual identity decision (the generic
RFC-46 ecosystem fuser is first-class alongside the sealed-safety product).

The missing piece is a profile signal. ADR-7 already names it: two attested
profiles (open/ecosystem + sealed-safety). ADR-4 enforcement belongs to the
sealed-safety profile, not to "attestation is on". Reshaped proposal, if wanted:

Add an explicit safety-profile selector (e.g. --profile safety). Under it,
advisory safety checks become hard errors — starting with ADR-4 (Auto must not
resolve a safety-relevant property; --memory must be stated). Default/ecosystem
profile behavior is unchanged.

That is a small, honest first brick of ADR-7's profile requirement — and it also
gives the per-boundary "declared/attested/observable" surface a natural home. Not
started; flagged for a decision.