Generic port menu callbacks could mutate scheduler threads and audio streams while the emulator worker was active. Route both disconnect and connect actions through one Program::Guard-protected helper and add a deterministic concurrent regression test.
The CPU keeps a free-running cycle counter (COUNT) that guest software
reads to measure elapsed time. Internally the emulator does not update
that counter after every instruction: cycles are accumulated in a
running clock and only folded into COUNT when the CPU synchronizes with
the rest of the machine. Reading the register returned the folded value
only, ignoring any cycles accumulated since the last fold, so the value
handed back to software could be stale.
How stale depends on how often synchronization happens, which is why
this was mostly invisible with the interpreter and clearly wrong with
the recompiler. The interpreter synchronizes after every instruction, so
at most one instruction worth of cycles was missing. The recompiler
translates a whole run of instructions into a single unit of host code
and only folds the accumulated cycles at its boundaries, so several
consecutive reads of COUNT inside one such unit all returned the exact
same number. Code that reads the counter repeatedly to check that time
is moving forward would see it standing still; the test_timer_ticks test
in the libdragon test suite fails this way, with two successive readings
comparing equal.
Track how many cycles have already been folded into COUNT in a separate
countClock field, so the cycles accumulated since then can be recovered
at any point. Reading COUNT now folds those pending cycles in first,
which both returns an up-to-date value and evaluates the COMPARE match
at the same moment, keeping the register and the timer interrupt
consistent with each other. Writing COUNT or COMPARE folds them in as
well, so the pending cycles are attributed to the old value rather than
being added on top of the newly written one.
The CPU has a free-running cycle counter (COUNT) and a programmable
target register (COMPARE); an interrupt is raised whenever the counter
reaches the target. The check for that event was written as
"count < compare && count + elapsed >= compare", which assumes the
target always lies ahead of the current counter value in plain
arithmetic order. Since both registers are unsigned, that assumption
breaks as soon as the target is behind the counter, and it breaks
permanently when the target is exactly zero: no unsigned value is ever
less than zero, so the first half of the condition is never true and the
interrupt is never raised at all.
That is not a corner case in practice. The counter is only 32 bits wide
and wraps around roughly every 90 seconds, so software that wants to
maintain a wider timestamp typically arms the target at zero in order to
be notified on every wrap. libdragon did exactly this: timer_init()
programs COMPARE to zero and used the resulting interrupt to increment
the high half of a 64-bit tick counter. Under ares that interrupt never
arrived, so the high half was never incremented and timer_ticks() went
backwards across a wrap, which is what the test_timer_ticks test in the
libdragon test suite reports.
Replace the ordered comparison with a modular distance computed over the
counter's full range: the number of ticks remaining until the target is
(compare - count) truncated to the counter width, and the interrupt
fires when at least that many ticks elapse. This behaves identically
when the target is ahead of the counter and additionally handles the
wrap-around case, including a target of zero. The counter update, the
crossing check and the cycle profiling counters are moved together into
a new stepCount() helper so that a single implementation stays
authoritative.
The client can now ask the stub to deliver chosen signals without stopping
or reporting (gdb sends QPassSignals automatically for signals configured
'handle <sig> nostop noprint pass'). Advertised in qSupported; the pass set
is client state, cleared on connect/disconnect like breakpoints.
Matthew Callis