Context
BA RFC #46 (bytecodealliance/rfcs#46) identifies multiply-instantiated modules as an open question for component lowering. A component may instantiate the same core module more than once, each needing its own memory and globals.
Meld does not currently handle this case.
Options (from RFC analysis)
| Option |
Trade-off |
| Reject (fail-fast) |
Safest. Clear error message. Limits component coverage. |
| Duplicate functions |
Full coverage but potential bloat. Leaf functions (no memory/globals) can be shared. |
| Multi-module output |
Full coverage, no bloat, but requires external linker metadata and new packaging format. |
STPA assessment
- Reject: no new hazards (safe default, aligns with SC-8/SC-9)
- Duplicate: H-3 (index remapping) applies per-instance; RH-5 (shared state semantics change); RL-5 (bloat)
- Multi-module: new trust surface (linker metadata format)
Recommendation
Start with reject (detect and report error). Add duplicate mode when real-world components require it — the existing merger infrastructure (index remapping, proven correct for N components) extends naturally to N instances of the same module.
Related
Context
BA RFC #46 (
bytecodealliance/rfcs#46) identifies multiply-instantiated modules as an open question for component lowering. A component may instantiate the same core module more than once, each needing its own memory and globals.Meld does not currently handle this case.
Options (from RFC analysis)
STPA assessment
Recommendation
Start with reject (detect and report error). Add duplicate mode when real-world components require it — the existing merger infrastructure (index remapping, proven correct for N components) extends naturally to N instances of the same module.
Related
safety/stpa/rfc46-comparative-analysis.md(gap MG-3)