wasm32_user_dlopen_load stages a .so through the same F28 exec-image slots as exec (binfmt_wasm.c), so wasm32_exec_image_max() = one slot = 16 MiB also caps dlopen. A full-language runtime shipped as a shared object exceeds that: CPython 3.13.5 as libpython3.13.so is ~39 MB unstripped, ~17.4 MB stripped — both refuse with -EFBIG:
binfmt_wasm: /usr/lib/libpython3.13.so is 40910266 bytes, over the 16777216-byte exec-image staging ceiling (strip debug info or grow the setup.c staging reservation)
PYDL-FAIL dlopen(/usr/lib/libpython3.13.so): ... host failed to stage/instantiate the shared object: File too large
Reproduction: glibc distro, M4 dynamic split of CPython 3.13.5 (wasmld -shared --export=Py_BytesMain), python3-dyn dlopens the .so at startup — refused before the host ever sees the bytes.
Proposed fix
Grow the setup.c reservation 2×16 → 2×48 MiB. The small-RAM guard still skips the reservation where it does not fit; the two-slot concurrent-exec model (busybox pipes) is unchanged. Verified end-to-end on the fra2 harness and on a deployed machine (dmitry/linux-6.12-glibc-dynamic-linking — Python 3.13.5 through the 17.4 MB .so).
Branch: BRINTOS-28-exec-staging Commit: 284eafe6c
A dynamic-sizing alternative (reserve from bootinfo RAM, or a transient non-reserved path for dlopen staging) may be preferable upstream — the branch is the minimal working form.
Proposed fix targets brintos/linux only — no distro submodule pins moved. All distros share one lineage, so pin bumps are coordinated on merge, not per-engineer.
