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>
color_ops.c is compiled twice -- once into libmux for the host, once into
the freestanding rv64 blob -- and the blob is then executed by two engines
of our own. That is four implementations of one source, and until now the
only differential we had compared the first against itself.
#2002 is where that bit. A cursor rewrite of the word-list functions was
verified on the host across 560,000 cases with a negative control, and it
still broke in the blob; the attempt was reverted with no root cause,
because reproducing it needed the blob under an external oracle and no box
had run one.
This adds that. One freestanding guest binary uses only Linux syscalls 64
and 93 -- exactly what dbt_test.cpp's ELF harness implements -- so
qemu-riscv64-static, rv64_interp_run and the DBT all execute the SAME
instruction stream rather than three builds of one source. The host leg
links the already-built libmux, which makes it the pre-change
implementation and therefore the specification, not a hand-written table
of expectations.
The battery is 16 fixed cases, 5 at the max_words cap, and 200 seeded
random cases driven by the same LCG on every route, so inputs are
identical by construction. 1,221 transcript lines. The cap cases earn
their place: a cap-check off-by-one moves 4 lines and the random leg
catches it never, while a common-path off-by-one moves 212. Both controls
were run.
What it found on first use is #2019 -- the DBT returns a wrong answer for
correct RV64 code when block chaining is enabled, intermittently. So the
#2002 rewrite was sound and the divergence was ours. repro/ carries that
reproducer: the rewrite as a patch (color_ops.c is generated -- a real
change belongs in color_ops.rl) and a script that loops it and reports a
rate, because a single run passes about half the time.
test-codiff joins TEST_TARGETS and passes on master. test-codiff-2019 is
deliberately NOT in `make test`: it is expected to fail. Both skip loudly
without a RISC-V cross-compiler rather than reporting a pass for a run
that compiled nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
