[Audit] bring the audit_61 branch probe onto sylpheed-re #2

Merged

fabi merged 1 commits from fix/audit61-onto-sylpheed-re into sylpheed-re 2026-09-21 16:03:11 +00:00

Conversation 0 Commits 1 Files Changed 4 +448 -19

fabi commented 2026-09-20 18:58:07 +00:00

Owner

Copy Link

Closes #1. --audit_61_branch_probe_pcs existed only on phase-a-tracing and the 2026-07-28 snapshot, so /sylph-canary could not work — it drives probe runs and parses hit counts. Measured, not assumed: strings on both built binaries gave zero hits for the cvar.

Merge, not rebuild

phase-a-tracing is 1 commit past the common ancestor; sylpheed-re is 232 commits ahead of it. Rebuilding from that branch would have discarded all 232, including the RE-INPUT/RE-DRAW instrumentation. Bringing the one commit forward is the cheap direction.

Cherry-picked a15430902 — 30d05ee97, the other commit named in #1, does not introduce the probe; it is the cross-build snapshot.

The three conflicts, each resolved on evidence

• kernel/event_log.cc looked like two rival implementations (726 vs 709 lines). It is not: they share 709 lines and differ by 19 — ours is a strict superset, phase-a's file plus a later phase_a_fileio_only mode that suppresses per-export log spam. Took ours whole.
• cpu/cpu_flags.{cc,h} taken as a verified union, not hand-edited conflict markers. Theirs contributes 11 cvars (audit_61 plus audit_67/68/69/70), ours contributes phase_a_fileio_only and kernel_emit_contention. I then asserted no flag present on either side was missing from the result.

🔴 That assertion earned its keep — it caught kernel_emit_contention, which a plain "take theirs" drops silently. My first pass did drop it.

All ten probe cvars are referenced by the cleanly-merged x64_emitter.cc / ppc_hir_builder.cc, so they are load-bearing. The three audit_jit_prolog_* cvars that look undeclared are DEFINE_uint32 in the translation unit that uses them — pre-existing on sylpheed-re, not this merge.

Built and verified

Incremental build, 705/705 steps, 0 errors (capped at 6 GB / -j3, since an unbounded build has frozen this box before). strings on the new bin/Linux/Checked/xenia_canary:

	before	after
audit_61_branch_probe_pcs	0	8 ✅
RE-INPUT / RE-DRAW	4	4 ✅ preserved
phase_a_fileio_only	—	8 ✅
kernel_emit_contention	—	8 ✅

⚠️ Only the Checked config is a target in this build dir — bin/Linux/Release/xenia_canary is not buildable here (0 ninja steps) and still dates from 2026-08-28 without the probe. So the instrumented oracle is the Checked binary, and the launchers that default to Release need pointing at it. Handled separately in the Sylpheed repo.

Not run from here: the standing rule is never to judge a Canary run launched from Bash. Probe runs go through tools/run-canary-safe.sh.

Closes #1. `--audit_61_branch_probe_pcs` existed only on `phase-a-tracing` and the 2026-07-28 snapshot, so **`/sylph-canary` could not work** — it drives probe runs and parses hit counts. Measured, not assumed: `strings` on both built binaries gave **zero** hits for the cvar. ## Merge, not rebuild `phase-a-tracing` is **1 commit** past the common ancestor; `sylpheed-re` is **232 commits** ahead of it. Rebuilding from that branch would have discarded all 232, including the `RE-INPUT`/`RE-DRAW` instrumentation. Bringing the one commit forward is the cheap direction. Cherry-picked **a15430902** — `30d05ee97`, the other commit named in #1, does *not* introduce the probe; it is the cross-build snapshot. ## The three conflicts, each resolved on evidence - **`kernel/event_log.cc`** looked like two rival implementations (726 vs 709 lines). It is not: they share **709 lines and differ by 19** — ours is a strict **superset**, phase-a's file plus a later `phase_a_fileio_only` mode that suppresses per-export log spam. Took ours whole. - **`cpu/cpu_flags.{cc,h}`** taken as a **verified union**, not hand-edited conflict markers. Theirs contributes 11 cvars (`audit_61` plus `audit_67/68/69/70`), ours contributes `phase_a_fileio_only` and `kernel_emit_contention`. I then asserted no flag present on either side was missing from the result. 🔴 **That assertion earned its keep** — it caught `kernel_emit_contention`, which a plain "take theirs" drops silently. My first pass did drop it. All ten probe cvars are referenced by the cleanly-merged `x64_emitter.cc` / `ppc_hir_builder.cc`, so they are load-bearing. The three `audit_jit_prolog_*` cvars that look undeclared are `DEFINE_uint32` in the translation unit that uses them — pre-existing on `sylpheed-re`, not this merge. ## Built and verified Incremental build, **705/705 steps, 0 errors** (capped at 6 GB / `-j3`, since an unbounded build has frozen this box before). `strings` on the new `bin/Linux/Checked/xenia_canary`: | | before | after | |---|---|---| | `audit_61_branch_probe_pcs` | 0 | **8** ✅ | | `RE-INPUT` / `RE-DRAW` | 4 | **4** ✅ preserved | | `phase_a_fileio_only` | — | **8** ✅ | | `kernel_emit_contention` | — | **8** ✅ | ⚠️ **Only the `Checked` config is a target in this build dir** — `bin/Linux/Release/xenia_canary` is not buildable here (0 ninja steps) and still dates from 2026-08-28 without the probe. So the instrumented oracle is the **Checked** binary, and the launchers that default to Release need pointing at it. Handled separately in the Sylpheed repo. Not run from here: the standing rule is never to judge a Canary run launched from Bash. Probe runs go through `tools/run-canary-safe.sh`.

fabi added 1 commit 2026-09-20 18:58:07 +00:00

[Audit] bring the audit_61 branch probe onto sylpheed-re ... fcdc2659fc

Fork issue #1: `--audit_61_branch_probe_pcs` existed only on
`phase-a-tracing` and the 2026-07-28 snapshot, so `/sylph-canary` -- which
drives probe runs and parses hit counts -- could not work. Measured, not
assumed: `strings` on both built binaries gives zero hits for the cvar.

MERGE, NOT REBUILD. `phase-a-tracing` is ONE commit past the common ancestor
while `sylpheed-re` is 232 commits ahead of it, so rebuilding from that branch
would have discarded 232 commits including the RE-INPUT/RE-DRAW instrumentation.
Bringing the one commit forward is the cheap direction.

Cherry-picked a15430902 (30d05ee97 does NOT introduce the probe -- it is the
cross-build snapshot). Three conflicts, each resolved on evidence:

  * `kernel/event_log.cc` looked like two rival implementations -- 726 lines
    vs 709 -- but they share 709 lines and differ by 19: ours is a strict
    SUPERSET, phase-a's file plus a later `phase_a_fileio_only` mode that
    suppresses per-export log spam. Took ours whole.
  * `cpu/cpu_flags.{cc,h}`: taken as a verified UNION rather than hand-edited.
    Theirs contributes 11 cvars (audit_61 plus audit_67/68/69/70 and the demo
    marker); ours contributes `phase_a_fileio_only` and
    `kernel_emit_contention`. Asserted afterwards that no flag present on
    either side is missing from the result -- which caught
    `kernel_emit_contention`, that a take-theirs would have dropped silently.

All ten probe cvars are referenced by the cleanly-merged `x64_emitter.cc` and
`ppc_hir_builder.cc`, so they are load-bearing, not decoration. The three
`audit_jit_prolog_*` cvars that look undeclared are DEFINE_uint32 in the
translation unit that uses them -- pre-existing on sylpheed-re, not this merge.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fabi merged commit 0363cc6b7a into sylpheed-re 2026-09-21 16:03:11 +00:00

fabi referenced this issue from a commit 2026-09-21 16:03:11 +00:00

Merge pull request '[Audit] bring the audit_61 branch probe onto sylpheed-re' (#2) from fix/audit61-onto-sylpheed-re into sylpheed-re

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

fabi

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fabi/Xenia-Canary#2