Skip to content

vms-d1b: self-host spine #6 — MMK drives a real TCC compile in QEMU, byte-identical, zero-bash (CI gate) - #476

Merged
baron-3dl merged 3 commits into
mainfrom
vms-d1b-selfhost-ci-gate
Aug 13, 2026
Merged

baron-3dl merged 3 commits into
mainfrom
vms-d1b-selfhost-ci-gate

Conversation

@baron-3dl

Copy link
Copy Markdown
Contributor

Summit (vms-d1b / spine #6)

The shipped MMK.EXE drives a real TCC compile inside OVMX in QEMU, against a real /dev/vms — the first-ever TCC.EXE run inside QEMU, and the first time MMK drives a real toolchain step (not a DCL builtin) end to end.

MMK spawns a persistent DCL over VMS mailboxes and streams a descrip.mms whose action defines a foreign command TCC :== "$..." and invokes it to compile the real src/libvmssys/vms_string.c to an object. DCL activates the foreign command by fork()+execve() of the staged static TCC.EXE. The parent (which never runs a compiler) asserts the driven object is a valid ELF relocatable carrying vms_strlen and is byte-identical across two independent in-guest MMK-driven builds. Zero bash in the build path.

Closes spine #6 and the MMK-driven-EXECUTION residual of spine #5 (vms-fe4) for the compile stage.

What's here

  • tests/toolchain/mk_tcc_static.sh — tinycc as a plain static (musl) foreign-command image (the binary DCL fork+execve activates; no IMGACT/shareable staging).
  • tests/toolchain/run_tcc_static_component.sh + CMake toolchain-tcc-static-component — host proof the static TCC.EXE compiles the real runtime TUs to valid, byte-identical objects; asserts vms_math.c is the documented x86 tcc-blocked TU.
  • tests/qemu/test_syssvc_mmk_build.c — the QEMU suite (extends spine dcl: SHOW DEVICE row byte-exact + create_dir leak fix (vms-b9f round 5) #4's drive test); honest-skips 77 with no /dev/vms.
  • tests/qemu/Dockerfile — stages static TCC.EXE at SYS$SYSTEM, tinycc headers + musl stdint.h closure, and the real component source.
  • facility_defects.sh — new per-facility control mmk-build-image-not-activated (reddens exactly the 5 object assertions fast, no $HIBER wedge). Dedicated control, not a second suite on the sp_send=0 drive control (two ~50s wedges don't fit the 120s QEMU budget). Floor 96 → 97.

CI gate wiring

Plugs into the standing kernel-executive barrier, which builds the QEMU image from the checked-out tree (clean context) and runs the whole harness — gated every run, no new job.

Verified in QEMU

  • kernel-executive: 76/76 (mmk_build 7/7).
  • mmk-build-image-not-activated: reddens exactly the 5 object assertions, no strays, harness completes (no timeout); coverage clean (97 = floor 97).
  • executive-absent: mmk_build rc=77.
  • host toolchain-tcc-static-component: green.

BUILD.COM NOT retired (residual → spine #7)

Full compile→archive→LINK-to-image in-guest remains: vms_math.c not tcc-compilable on x86_64; LINK needs SYS$LIBRARY shareables staged + logical-name resolution + IMGACT activation. Documented in docs/design-self-host-spine5-mmk-component.md. No red gate shipped (Rule 6/7).

🤖 Generated with Claude Code

alice and others added 3 commits August 13, 2026 14:39
…byte-identical, zero-bash (CI gate)

The shipped MMK.EXE now drives a REAL toolchain step inside OVMX in QEMU,
against a real /dev/vms: it spawns a persistent DCL over VMS mailboxes and
streams a descrip.mms whose action defines a foreign command TCC :== "$..." and
invokes it to compile the REAL src/libvmssys freestanding runtime TU
vms_string.c to an object. DCL activates the foreign command by fork()+execve()
of the staged static TCC.EXE (a plain static image is not in-process-eligible,
so imgact_activate returns SS$_UNSUPPORTED and DCL forks it) — the FIRST-EVER
TCC.EXE run inside QEMU and the first time MMK drives a real compiler (not a DCL
builtin) end to end. The parent (which never runs a compiler) asserts the driven
object is a valid ELF relocatable carrying vms_strlen and is BYTE-IDENTICAL
across two independent in-guest MMK-driven builds. Zero bash in the build path.

This closes spine #6 (vms-d1b, the CI gate) and the MMK-driven-EXECUTION residual
of spine #5 (vms-fe4) for the COMPILE stage.

- tests/toolchain/mk_tcc_static.sh: builds tinycc as a PLAIN STATIC (musl)
  foreign-command image (distinct from mk_tcc.sh's IMGACT-packaged self-host
  image) — the binary DCL fork+execve activates, no IMGACT/shareable staging.
- tests/toolchain/run_tcc_static_component.sh + CMake test
  toolchain-tcc-static-component: host proof the static TCC.EXE compiles the real
  runtime TUs (vms_string/vms_snprintf/driver) to valid, byte-identical objects;
  asserts vms_math.c is the documented x86 tcc-blocked TU (SSE "x" inline asm).
- tests/qemu/test_syssvc_mmk_build.c: the QEMU suite (extends spine #4's
  test_syssvc_mmk_drive.c); honest-skips 77 with no /dev/vms.
- tests/qemu/Dockerfile: stages static TCC.EXE at SYS$SYSTEM, tinycc's headers +
  musl's stdint.h closure beside it, and the real component source. The suite
  plugs into the STANDING kernel-executive CI barrier (builds the image from the
  checked-out tree, a clean context), so the MMK-driven native build is gated on
  every run — no new job.
- facility_defects.sh: new per-facility control mmk-build-image-not-activated —
  dcl_exec_foreign_command reports success WITHOUT activating the image, so the
  driven TCC command completes but runs no compiler; reddens exactly the suite's
  five object/byte-identity assertions FAST (no $HIBER wedge), attributable to
  the build drive alone. A DEDICATED control, not a second suite on the
  sp_send=0 drive control: two ~50s $HIBER wedges do not fit run_tests.sh's 120s
  QEMU budget in one boot. Floor 96 -> 97.

Verified in QEMU on this host: kernel-executive 76/76 (mmk_build 7/7);
mmk-build-image-not-activated reddens exactly the 5 object assertions with no
strays and the harness completes (no timeout); executive-absent mmk_build rc=77.

BUILD.COM retirement is NOT done: the full compile->archive->LINK-to-image chain
in-guest remains (vms_math not tcc-compilable on x86_64; LINK needs the
SYS$LIBRARY shareables staged + logical-name resolution in LINK.EXE + IMGACT
activation) — the precise residual for spine #7, documented in
docs/design-self-host-spine5-mmk-component.md. No red gate shipped (Rule 6/7).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ous bound), not a 2s reap grace

CI's Kernel Executive job went red from a clean build: mmk_build produced the
object and echoed the marker (build-#1 assertions GREEN) but MMK had not yet
finished tearing down its spawned DCL within the tight 2s REAP_GRACE, so reap1
stayed 0, the reap1 short-circuit skipped drive #2, and the completion +
byte-identity assertions reddened. CI's TCG is much slower than the dev host,
where reap1 was always 1.

Restructure drive_build to a SINGLE generous bounded wait (40s) that drains
output (detecting the marker) AND polls for MMK to exit, returning the instant
MMK exits -- so a green drive costs only its real runtime and the bound is only
ever hit by a genuine hang. Removes the split 10s-marker / 2s-reap phases that
were sized for a fast dev host.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…nstead of waiting on MMK's exit

The clean-build repro showed mmk_build's remaining flake was MMK's slow
self-exit under contended TCG: the compile finished, the marker was echoed and
the byte-identical object was on disk, but MMK had not yet torn down its spawned
DCL and exited within the bound, so the reap-based assertion reddened. MMK's
exit timing is not a property this suite tests.

drive_build now stops the instant the PROOF is captured -- the DCL echoed
OVMXD1B:COMPILED AND the object exists on disk -- and kills MMK as cleanup rather
than gating on its self-exit. A genuine mid-drive $HIBER deadlock still fails
hard (no marker is ever echoed). The completion assertion is now the marker
(reliable), the reap-exit assertion is dropped, and the drive-#2 short-circuit is
keyed on the object (robust under load), not on MMK's exit. The negctl declared
set is unchanged (the 5 object/byte-identity assertions; the marker stays green).

Verified: two consecutive clean green runs (mmk_build 6/6), and
mmk-build-image-not-activated reddens exactly the 5 object assertions with the
marker green. (A QEMU timeout / mmk_drive reap-flake seen intermittently here is
this 10-container dev host's load, not the code: on CI the harness completed and
mmk_drive passed.)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@baron-3dl
baron-3dl merged commit 5dcec90 into main Aug 13, 2026
66 checks passed
baron-3dl added a commit that referenced this pull request Aug 13, 2026
…tes real OVMX code) (#500)

Bump OVMX_PRODUCT_VERSION V0.4-3 → V0.4-4. ~12 PRs since V0.4-3. Headline:
OVMX's own toolchain now builds real OVMX code to a running image INSIDE OVMX.

  SELF-HOST IN-GUEST   MMK.EXE drives TCC→LIBRARIAN→LINK over its mailbox DCL vs
                       real /dev/vms: #476 compile-in-QEMU (first-ever TCC-in-guest),
                       #488 archive, #493 full compile→archive→LINK→ACTIVATE (linked
                       OVMXRT.EXE IMGACT-activates + runs, exit 216), byte-identical,
                       CI-gated from clean archive. (BUILD.COM retirement → vms-89d.)
  UX FIDELITY          #461 DIRECTORY wildcards/ellipsis · #478 COPY/DELETE/RENAME
                       (explicit-version DELETE) · #481 HELP .HLB library · #487 SET
                       SYMBOL scope · #491 DCL ON/SET NOON error control
  BOOT INTEGRITY       #499 boot-smoke green (aligned 3 e2e tests to authentic
                       DELETE/DIRECTORY output; strengthened the fail-stop guard)
  + swept other threads' merged work

Co-authored-by: alice <alice@workspace.local>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant