Define the T14 LLVM bar as a libc++ stage-3 recipe with an in-tree judge; the bar value is owed

Cargo.toml

@@ -36,6 +36,7 @@ members = [
     "toyos-inspect",
     "toyos-keymap",
     "toyos-ld",
+    "toyos-llvmbar",
     "toyos-libc-copies",
     "toyos-logstream",
     "toyos-manifest",

issues/build/toyos-builds-itself.md

@@ -53,6 +53,94 @@ enough for an LLVM build tree
 memory beyond what 2 MiB process pages allow
 (`issues/kernel/process-memory-is-2-mib-pages-and-that-caps-the-process-count.md`).
 
+**The bar: Linux on this T14 building the same LLVM with a clang-built
+clang+lld against libc++.** It is a recipe, and a ToyOS run matches every
+element of it. `toyos-llvmbar` holds its lines (`t14/block.txt`), the steps
+the T14 runs (`t14/`), the power envelope and the judge, whose module header
+is the rule a sample is valid by.
+
+- *Source*: `rust-lang/llvm-project` at
+  `52ed14fcd56afc30f9cccd8ca8ce237c2eef7e04`. A ToyOS run's source, for
+  the building compiler and the build alike, differs from it by nothing
+  but the fork's commits over that base (`forks.toml`, `[llvm-project]`).
+- *Building compiler*: clang+lld at `52ed14fc`, Release,
+  `LLVM_ENABLE_LTO=OFF`, `LLVM_BUILD_INSTRUMENTED=OFF`, no profile data,
+  built by clang+lld at `52ed14fc` with the same configuration and flags:
+  the `s2` lines. Stage 1 is only how the first clang exists: gcc, which
+  has no ToyOS target, builds it with the `s1` lines
+  (`gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0`). For ToyOS it is M2's
+  cross build of the same source and configuration, whose lines M2 owes.
+- *C++ library*: libc++ with libc++abi from the same source, built in each
+  stage's build by that stage's own clang (`runtimes`). The `s2` tools link
+  it statically: `s2`'s `clang-22` and `lld` name no C++ shared object and
+  reference no `GLIBCXX` symbol. `s2`'s libc++ headers are
+  `_LIBCPP_VERSION` 220108.
+- *Build*: that clang+lld builds clang+lld from the same source with the
+  `s3` lines, configured afresh; cmake 3.28.3, ninja 1.11.1.
+- *Timed span*: the last line's `ninja` alone.
+- *Warm*: a span's configure line starts as soon as a complete `s3`
+  `ninja` line exits, and its `ninja` as soon as that configure exits; the
+  build reads no block from a block device during the span (`time -v`'s
+  file system inputs 0).
+- *Power envelope*: `toyos-llvmbar`'s `ENVELOPE` and `ENVELOPE_EVERY_CPU`,
+  every element with its value; `LINUX` and `LINUX_EVERY_CPU` are how Linux
+  reaches them.
+- *Machine*: i5-1135G7, 8 threads, 16476082176 B RAM; microcode revision
+  `0xbe` on every CPU; Ubuntu 24.04.4 with the kernel
+  `issues/hardware/linuxs-readings-of-the-t14-and-the-tcg-model-are-not-committed.md`
+  pins, 6.8.0-142-generic; ext4 on LVM.
+- *Mitigations*: that issue's T14 capture is the one read of them. A sample
+  reads the kernel, the vulnerabilities and the microcode at its start and
+  its end with the capture's own commands, and the judge refuses it unless
+  they are the capture's.
+
+The bar is the best of three valid samples, and it is not set: no sample is
+valid by the judge.
+
+Owed once the T14 answers again
+(`issues/hardware/a-t14-measurement-has-no-way-back-when-the-t14-stops-answering.md`),
+and Ubuntu is wiped only after the capture and the bar are both committed:
+
+- the capture on `main`, whose `/proc/version`, vulnerabilities and
+  `/proc/cpuinfo` text is the judge's second argument;
+- `t14/driver.sh` under `t14/sampler.sh`, run until `toyos-llvmbar` exits
+  0, and the bar, the BIOS version and the kernel command line it prints
+  recorded here;
+- *Flags*, of `s2` and `s3`: the `CMAKE_*_FLAGS` and linker flags the
+  run's `*-cache.txt` hold, and the compile line `s3-commands.txt` holds
+  for `clang/tools/driver/driver.cpp` and the link line for `clang`, which
+  show whether `$LIBCXX` added `-stdlib=libc++` and `-static-libstdc++`;
+- `s2-commands.txt` and `s3-commands.txt` compared: they may differ only in
+  the build directory.
+
+*Exit*: a ToyOS build of the source above with the `s3` configuration and
+flags, by a clang+lld built by the recipe above, on this T14, warm, whose
+`ninja` exits 0 at or under the bar, read back as the judge reads a Linux
+sample: the envelope at its cadence from a start read to an end read, and at
+the span's start and end the microcode, the BIOS version (SMBIOS type 0)
+equal to the Linux sample's, and for each entry the capture shows as a
+mitigation the line
+`issues/kernel/each-boot-prints-the-vulnerabilities-lines-linux-prints.md`
+requires, with its mechanism in force on every CPU:
+
+- `gather_data_sampling`: `IA32_MCU_OPT_CTRL` (0x123) `GDS_MITG_DIS` clear
+  (`issues/kernel/spec-ctrl-and-gds-stay-as-firmware-left-them.md`);
+- `spectre_v2`: `IA32_SPEC_CTRL` (0x48) at the capture's read with SSBD
+  masked (the same issue);
+- `indirect_target_selection`: the live thunk bodies equal to the body
+  `issues/kernel/a-pure-function-decides-a-cpus-speculation-mitigations-as-linux-does.md`
+  selects (`issues/kernel/indirect-branches-and-returns-run-without-thunks.md`);
+- `spectre_v1`: CR4.SMAP set
+  (`issues/kernel/user-pointer-checks-have-no-spectre-v1-fence-and-smap-is-optional.md`);
+- `spec_store_bypass`: where the capture shows Linux's prctl mode, SSBD is
+  set only in a process that asked, so parity is SSBD set in exactly the
+  build's processes that ask Linux, read on the switch into each
+  (`issues/kernel/no-program-runs-with-speculative-store-bypass-disabled.md`);
+  which of them ask is owed.
+
+An entry the capture shows as a mitigation that this list does not name holds
+the exit until it is named here.
+
 **What M2 must do to delete toyos-ld.** It is frozen and links nothing the host
 builds; what keeps it is that it is the one linker a ToyOS process can run,
 shipped as `/system/bin/toyos-ld` by `system.toml`'s `[programs]` row and named

issues/hardware/a-t14-measurement-has-no-way-back-when-the-t14-stops-answering.md

@@ -0,0 +1,20 @@
+---
+status: open
+kind: tooling
+opened: 2026-09-28
+---
+
+# A T14 measurement has no way back when the T14 stops answering
+
+A measurement under the T14's Ubuntu, such as the LLVM bar in
+`issues/build/toyos-builds-itself.md`, is driven and read over ssh to
+`t14@192.168.1.46`. At about 19:20Z on 2026-09-28, during the bar's `s3-2`
+span, the T14 stopped answering ping and ssh, so the run's state, and whether
+its driver and root sampler still run, cannot be read. Which of the T14's
+links that address is on is unread; `ip route get` to the development Mac,
+run on the T14, reads it.
+
+Owner: the orchestrator, which runs the T14
+(`issues/hardware/the-t14-answers-only-through-a-usb-stick.md`). Exit: a second
+path to the T14 under Ubuntu, independent of the link that address is on, that
+the orchestrator reaches when that link is down.

toyos-llvmbar/Cargo.toml

@@ -0,0 +1,13 @@
+# A member of the host workspace (root `Cargo.toml`): the T14 LLVM bar's steps
+# and its judge.
+
+[package]
+name = "toyos-llvmbar"
+description = "The T14 LLVM bar: the steps its Linux run takes on the T14, and the judge of the files they write."
+version = "0.1.0"
+edition = "2021"
+license = "MIT OR Apache-2.0"
+publish = false
+
+[lints.rust]
+warnings = "deny"