mirror of
https://github.com/brazilofmux/tinymux
synced 2026-08-13 00:23:11 -04:00
cebb416c19
Knowing chaining is the mechanism does not say WHICH chained edge is wrong, and with 70 of them in the reproducer that is the difference between a lead and a location. 2019-chain-bisect.patch adds two scratch knobs to dbt.cpp -- list the chain targets, and suppress named ones -- and bisect.sh binary-searches for the smallest set whose suppression makes the failure go away. It is a debugging patch, not a proposed change: nothing here is meant to be merged into the engine. It converges on one PC out of 70. Skipping that edge alone: 0/40 wrong. Skipping the TAKEN side of the same branch: 19/40. Skipping wc_next's own entry: 28/40. Skipping an arbitrary other edge: 28/40. So the fault is one specific edge rather than chaining being generally fragile here. That edge is the fall-through of a shrink-wrapped early-out: gcc sank wc_next's prologue below the `finished` test, which makes the fall-through target both a mid-function entry point and a PC that is not a branch target in the guest at all -- control simply continues into it. Its sibling, a real branch target, chains correctly. The sampling matters and is documented in the script: at ~50% failure, "0 wrong" over 30 runs is a false clean with probability about 1e-9, and lowering RUNS quietly turns the bisection into a coin flip. runner.cpp gains the two hooks the patch defines. They are declared __attribute__((weak)) and null-checked, because a normal build links the unpatched dbt.cpp and defines neither -- declaring them plainly breaks `make test-codiff` at link time, which is how the first version of this commit was wrong. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| repro | ||
| .gitignore | ||
| cases.h | ||
| guest_main.c | ||
| host_main.c | ||
| min_main.c | ||
| run.sh | ||
| runner.cpp | ||