fix(decoder): give the container the Canary it is supposed to run
Some checks failed
CI / Native — linux (pull_request) Failing after 1h1m35s
CI / WASM — Web (pull_request) Successful in 24m37s
CI / Formatting (pull_request) Successful in 26s

The database mount below was one of three ways the decoder could not reach its
own oracle. The other two are here.

`run-canary` never looked in `Checked/`. It tried `Release/` then `Debug/`, and
both of those exist on this box -- an Aug 28 binary and a Jul 19 one. They boot
the game perfectly well and carry NO `audit_61` branch probe, so a probe run
against either returns zero hits that read as a finding about the game rather
than as a stale binary. Configuration is now the outer loop and location the
inner one, so a `Checked` build anywhere beats a `Release` build anywhere;
`$XENIA_BIN` still overrides everything. Measured here: `Checked` has
`audit_61_branch_probe_pcs`, `Release` and `Debug` do not.

The launcher also now says which instrumentation is missing BEFORE the run,
because the alternative is reading an empty log afterwards and guessing.

`build-canary` built `$PROJECT_DIR/xenia-canary`, which does not exist in this
container -- the source is bind-mounted at `/canary` and the launcher already
exports `XENIA_SRC=/canary`. CONTAINER-NOTES has carried that defect since
2026-08-29 with a symlink workaround and a warning to remember to delete the
symlink afterwards. It now reads `$XENIA_SRC` first, so there is nothing to
remember. Its default configuration moves Release -> Checked to match what
`run-canary` picks; the old default spent a full build on a binary nothing ran.

Two documented blockers are refuted rather than deleted, since the sequence of
wrong readings is what makes the right one checkable: the CONTAINER-NOTES
symlink dance (the warm build volume it was configured against is gone too,
removed in the 2026-09-18 cleanup, so the next build configures cleanly against
`/canary`), and `upstream-baseline.md`'s "`version.h` is never generated" --
`CMakeLists.txt` generates it at configure time now, with a stub fallback.

`decoder-loop.md` claimed the oracle was at `Linux/Release/` and that the probe
was on two side branches; both were true when written and neither is now.

Verified: five pick_bin cases against the extracted function body, and `strings`
on all three real binaries.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
MechaCat02
2026-09-21 18:08:10 +02:00
parent 8108958a77
commit 1fdbb5f197
5 changed files with 69 additions and 26 deletions

View File

@@ -10,11 +10,22 @@
# AVAILABLE MEMORY as well as core count — a full-parallel build of this tree
# has OOM-killed the host outright.
#
# build-canary [Release|Debug] [extra cmake --build args]
# `Checked` is the default, and should stay it: it is what the host builds and
# what `run-canary` picks first, so the two agree by construction. Building
# `Release` here instead leaves a second binary that `run-canary` will not use
# -- hours of CPU for something nothing runs. `Checked` is optimised, with
# assertions left in.
#
# build-canary [Checked|Release|Debug] [extra cmake --build args]
set -euo pipefail
CONFIG="${1:-Release}"; shift || true
SRC="${PROJECT_DIR:-/work}/xenia-canary"
CONFIG="${1:-Checked}"; shift || true
# $XENIA_SRC FIRST. In this container the Canary source is bind-mounted at
# `/canary`, and `$PROJECT_DIR/xenia-canary` does not exist -- so the old default
# made this script unusable here, and the documented workaround was to symlink
# `/canary` into the repository and remember to delete it again (CONTAINER-NOTES
# §"The toolchain is real"). The launcher already exports the right path; read it.
SRC="${XENIA_SRC:-${PROJECT_DIR:-/work}/xenia-canary}"
BUILD="${XENIA_BUILD_DIR:-/sylph-home/re/canary-build}"
JOBS="${SYLPH_JOBS:-2}"

View File

@@ -48,14 +48,25 @@ fi
PROJECT_DIR="${PROJECT_DIR:-/work}"
# ── Binary ───────────────────────────────────────────────────────────────────
# `Checked` FIRST. All three configurations can be built, but `Checked` is the
# one this project actually builds, so it is the one carrying our
# instrumentation; the `Release/` and `Debug/` binaries beside it are months-old
# leftovers that still run and still boot the game, which is exactly what makes
# them dangerous -- a probe run against one reports zero hits and reads as a
# finding about the game. Measured on this box 2026-09-21: `Checked` has
# `audit_61_branch_probe_pcs`, `Release` (Aug 28) and `Debug` (Jul 19) do not.
pick_bin() {
[ -n "${XENIA_BIN:-}" ] && { echo "$XENIA_BIN"; return; }
for c in \
"${XENIA_BUILD_DIR:-/sylph-home/re/canary-build}/bin/Linux/Release/xenia_canary" \
"${XENIA_BUILD_DIR:-/sylph-home/re/canary-build}/bin/Linux/Debug/xenia_canary" \
"$PROJECT_DIR/xenia-canary/build/bin/Linux/Release/xenia_canary" \
"$PROJECT_DIR/xenia-canary/build/bin/Linux/Debug/xenia_canary"; do
[ -x "$c" ] && { echo "$c"; return; }
# Configuration is the OUTER loop, location the inner one: a `Checked` build
# anywhere beats a `Release` build anywhere. The other order picks a stale
# container `Release` over a fresh instrumented repo `Checked`, which is the
# exact mistake this is here to stop.
for cfg in Checked Release Debug; do
for c in \
"${XENIA_BUILD_DIR:-/sylph-home/re/canary-build}/bin/Linux/$cfg/xenia_canary" \
"$PROJECT_DIR/xenia-canary/build/bin/Linux/$cfg/xenia_canary"; do
[ -x "$c" ] && { echo "$c"; return; }
done
done
}
BIN="$(pick_bin)"
@@ -64,6 +75,13 @@ if [ -z "${BIN:-}" ]; then
exit 1
fi
# Say what is in the binary before the run, not after reading an empty log.
# A missing probe is a build that predates it, never a quiet game.
for sym in audit_61_branch_probe_pcs RE-DRAW; do
grep -aqm1 -- "$sym" "$BIN" \
|| echo "run-canary: ⚠ $BIN has NO '$sym' -- it predates that instrumentation. Rebuild with: build-canary" >&2
done
# ── ISO ──────────────────────────────────────────────────────────────────────
ISO="${SYLPH_ISO:-}"
if [ -z "$ISO" ]; then