COD-3218 / COD-3440: remove the LD_PRELOAD hack and port exec-harness to musl

[moha-bekh]

Review only — not for merging. Opened as a draft to collect feedback. Two throwaway
CI workflows are in the diff on purpose (see the last section) and must be removed before
anything lands on main.

Covers COD-3218 (remove the LD_PRELOAD hack) and the exec-harness half of
COD-3440 (port the components to musl). They are the same problem: the preload was the
only thing keeping exec-harness on gnu.

Why

COD-3440 wants one multi-call binary, which requires the runner, exec-harness and
memtrack to target the same libc. The runner is musl; the other two were gnu. A statically
linked musl binary can't be preloaded into a glibc process, so the musl port was blocked on
removing the LD_PRELOAD mechanism.

What changed

exec-harness no longer injects libcodspeed_preload.so. It toggles instrumentation in
its own process, around the spawn of each benchmark command. Callgrind records the spawn edge
on the dump part live at fork time, and set_executed_benchmark names that same part with
the benchmark URI, so COD-2349's spawn-chain walk attributes the child's whole trace to the
benchmark. Confirmed on real dumps — the URI and the spawn edge land on the same part:

part: 2
desc: Spawned pid: 12570
desc: Trigger: Client Request: exec_harness::cod3218_probe
totals: 339979

The whole preload inventory is gone: the C source, the include_bytes! + temp-file
extraction, the LD_PRELOAD compatibility check, the shared-library build in build.rs,
and the cc / object dependencies. perform_with_valgrind collapses into perform.

Removes a user-facing limitation. Deleting the LD_PRELOAD check removes the "CPU
Simulation mode does not support statically linked binaries" error — nothing has to be
injected into the benchmarked executable any more.

Runner side, four substantive lines. --instr-atstart=inherit is required: measured,
with no the child dumps a single zero-cost part and the benchmark reports nothing at all,
so COD-2349's argv-injection channel is not sufficient on its own. Rather than making it
unconditional in measure.rs (left untouched), it is derived in
executor_config_for_command, which already received uses_exec_harness:

enable_introspection: !uses_exec_harness,
simulation_track_subprocess: self.simulation_track_subprocess || uses_exec_harness,

So entrypoint runs (cargo codspeed run, pytest-codspeed) keep exactly their current
behaviour — an entrypoint benchmark that forks does not suddenly start counting its
children — and --simulation-track-subprocess keeps its original meaning.

Two guards against silent failure. Every failure mode on this path is mute: the harness
runs, the benchmark completes, exit code is 0, and the measurement is empty.

• exec-harness now hard-fails when is_instrumented() is false.
• instrument-hooks-bindings/build.rs no longer falls back to the noop implementation on
  Linux. It used to emit a cargo:warning and compile hooks that all return Ok(()) —
  reachable by accident, since building for a musl target with no musl C compiler on PATH
  is enough. Now a build failure, with the musl-tools hint. Non-Linux keeps the warning so
  macOS dev builds are unaffected.

Breaking change: the measurement baseline shifts

The measured region used to start in the child at the .so's ELF constructor — after fork,
after exec, after most of ld.so. It now starts in exec-harness before the fork, so it also
covers the fork/exec/wait path and the child's full pre-main startup.

Measured on x86_64 with the process shape held constant and only the work varying:

N (seq 1 N)	before	after	delta	ratio
1 000	407 704	1 350 987	943 283	×3.31
10 000	877 820	1 821 219	943 399	×2.07
100 000	5 592 827	6 535 673	942 846	×1.17
1 000 000	52 849 099	53 790 416	941 317	×1.018

It is a constant ~940k Ir per benchmark, not a percentage — stable to 0.22% across a
1000× range of benchmark size. Decomposes as ~340k for exec-harness's own fork/exec/wait
plus ~290–320k per spawned process (its pre-main startup); predicted vs measured matches
exactly on a 4-process probe. So it is under 1% for a benchmark above ~94M Ir and a large
relative shift for very short ones.

Heads-up for platform

Children no longer self-label with the URI. LD_PRELOAD used to be inherited by every
descendant, so each one issued its own DUMP_STATS_AT with the same URI and attribution
never needed the spawn chain. Now only exec-harness's dump carries it, so attribution rests
entirely on the spawn-chain walk — if that regresses, cost goes silently unattributed
rather than degrading. (It also fixes a gap: sh was previously unattributed.)

musl

With the .so gone, exec-harness builds for musl with no further change. Verified on CI
(x86_64): static-pie linked, no DT_NEEDED, no RPATH/RUNPATH, no interpreter — and the
static musl binary drives valgrind instrumentation correctly end to end, so callgrind client
requests work fine from a static musl binary.

musl costs ~100k Ir more than glibc in exec-harness's own fork/exec/wait region (+1.7% on
this probe); the children are identical to within noise, as they must be.

crates/memtrack/musl/argp.h is the declarations-only stub from the memtrack musl spike.
The rest of that recipe (autoconf cache seeds, LIBBPF_SYS_EXTRA_CFLAGS, -lgcc on
aarch64) is not in this branch — where those env vars should live so a plain
cargo build --target …-musl works both locally and in CI is still an open question, and
.cargo/config.toml's [env] would leak into the gnu build.

Verification

Exit code 0 proves nothing here, so the checks assert on .out content: a part carrying
the benchmark URI, a Spawned pid: edge on that same part, and non-zero cost for every
process in the chain, walked recursively. The probe nests spawns
(exec-harness → sh → seq/wc) so intermediate forwarding is exercised.

Two precautions keep it from passing vacuously: the runner silently downloads the released
exec-harness when the local one isn't on PATH, so the run is bracketed by a hash of the
binary; and the musl leg asserts the installed binary really has no dynamic dependency.

Last run: all six jobs green, on both gnu and static musl.

Local: fmt and clippy --all-targets -D warnings clean, cargo test -p exec-harness
25/25. Runner unit tests are identical to main (same pass/fail counts, same failure set).

The two workflows in this diff

.github/workflows/cod-3218-exec-harness-check.yml and cod-3440-musl-check.yml are
throwaway, workflow_dispatch plus a branch-scoped push trigger. They exist because
this work can't be validated on the dev machine (aarch64 Arch, no valgrind; the CodSpeed
valgrind .deb is Ubuntu-only). Both must be deleted before anything merges to main —
each says so in its header.

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 17 untouched benchmarks

---

_{Comparing spike/cod-3440-memtrack-musl (c83b2a5) with main (37eba9e)}