LLVM × openkal: clang and lld as ok images, one toolchain for every system #880

What

Build clang and lld themselves as openkal ok images (clang.okb, lld.okb): one toolchain artifact of both architectures that each system's okrun starts on Linux x64/arm64, macOS arm64 and Windows x64, instead of one LLVM package per host (today's xim llvm). The code it produces is unaffected: the image decides where the compiler runs, --target and the target's sysroot/SDK decide what it produces.

Where it starts

mcppls-clangd already builds most of clang for <arch>-openkal (openkal/clangd, okgen: llvm-project's libraries built by CMake from mcpp's contract — Support, TargetParser, MC, clang's Lex/Parse/Sema/AST/Serialization/Frontend/Driver, LLVM_TARGETS_TO_BUILD=X86;AArch64). clangd.okb parses at 0.72–1.09× the native clangd. A compiler adds CodeGen and the two backends, the driver and cc1 entry, and lld: the same okgen path with other link targets.

Prerequisites, in order

1. Shared executable mapping of an image's file region (openkal specification). okrun copies an image's segments into kal_exec_alloc memory, a private copy per process; a native program's text is shared through the page cache. A full clang is ~100–150 MB per architecture, so -j32 would hold 3–5 GB more than native. openkal would state mapping a region of an image file read-only and executable (W^X kept), which okb's 64 KiB member alignment (C2, docs/okb.md) was laid out for. This is the deciding prerequisite.
2. Start cost per invocation: after (1), the okb admission digest (chunk digests and SHA instructions: ~0.03 s); optionally clang's multi-TU or a compile service from mcpp.
3. Host decisions the driver makes at compile time, made at run time under __OPENKAL__: default target, executable suffix, response-file tokenizer, host toolchain selection; sys::ExecuteAndWait starting another image through the loader (kal_env_loader, as mcppls-clangd's module workers already do). An image cannot probe the Windows registry, xcrun or GCC installations by itself; it takes the paths mcpp's toolchain contract states.
4. openkal 0.19's processors, task priority and process identity (mcpp design 2026-10-30 part 2 §25.9), which clang's ThreadPool, LTO and module-cache locks rely on as clangd does.

Acceptance

• object files byte-identical to the same-version native clang for the same target and inputs (mcpp, mcppls, a subset of LLVM's test-suite);
• compile time at most 1.3× native;
• resident memory under -j N not growing with N beyond native's (checks prerequisite 1).

Then mcpp may take its LLVM toolchain from one okb row instead of one package per host.

Recorded from mcpp design 2026-10-30 part 2 rev 11 (§25.9, scope of the round). Not in the current round.