The asynchronous preemption stub saved and restored YMM0-15 with vmovdqa and ran vzeroupper in inline asm, which
-march=x86-64-v2 does not reach. The v2 runtime library therefore carried VEX code, and a CPU without AVX stopped
with an illegal instruction the first time a core owner was interrupted, a few seconds into boot (issue #454,
Pentium Gold G6400, totk+0xe7a2b50 = kern_ap_stub+0x20). Without __AVX__ the stub now saves XMM0-15 with movdqa into
the same slots; v2 game code keeps nothing in the upper YMM halves. The v3 stub is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SignalAndModifyByWaitingCountIfEqual with count <= 0 and at least one waiter stored value - 1; Horizon stores
value - 2 (mesosphere KAddressArbiter::SignalAndModifyByWaitingCountIfEqual; yuzu, LAS Recomp and nxnative agree).
The word was already updated with compare-and-swap, as LAS Recomp 1144aea made theirs; the count > 0 values were
right.
--probe-kernel arbiter part expected the old value: it now wants 4 for value 6 with one waiter and count -1, and
4 for two waiters and count 0. Before: 5 for both. After: ok.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ours took a pending CancelSynchronization first, before the signalled objects and before the timeout-0 return, so a
poll or a wait on a signalled object used it up and the blocking wait it was meant for ran on. Horizon checks a
signalled object, then timeout 0, then the cancel (mesosphere KSynchronizationObject::Wait; LAS Recomp 1144aea moved
the poll the same way): both keep it pending. A cancel that wakes a blocked wait still ends it cancelled:
CancelSynchronization now wakes it with R_CANCELLED, which the loop tells apart from a signal's -1.
--probe-kernel events part: a cancel sent before a poll and before a wait on a signalled event; each is followed by a
blocking wait with a 500 ms timeout. Before: the poll and the signalled wait returned 0xec01 (cancelled) and the
blocking waits timed out (0xea01). After: timeout, success, then cancelled both times.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The game destroys the nfp activate and deactivate events and attaches the same SystemEventType again before each
detection. kern_bind_system_event kept the first writable handle per guest address and returned early, so the second
Attach left the event destroyed and the game's next TryWaitSystemEvent aborted (issue #398, equipping the Amiibo
power). A kept handle now counts only while the SDK's state byte of the event is nonzero; otherwise the event is
created again and its entry takes the new handle, and a signal to a destroyed event is dropped. probe-services
destroys and attaches both nfp events again and checks that they work.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Reverts dafc35f: free_cores = 1 in totk.ini lifts the virtual core gate again, as in 0.2.8. The mode stays as an
experiment, and every place a player meets it says the game crashes: totk.ini.example, a WARNING line in the start log,
and a line under every crash report and FATAL while the gate is off (kern_free_cores_note), so a log from #212 names
the cause at once.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ExitThread went back to the thread start with longjmp on a buffer from a non-unwinding setjmp, whose frame field is 0.
When Control Flow Guard is on for the process, ucrtbase's longjmp checks the buffer first and ends the process with
fast fail 13 (0xc0000409) on a frame of 0: offset 0xb373c of ucrtbase 10.0.26100.9711, the offset in the event logs of
#222, #176 and #75. Exploit protection can force CFG on any program, and the first guest thread to exit, right after the
game's first six-axis read, killed the process with no line in the log; the abort and invalid-parameter handlers never
run for a fast fail.
plat_jmp_save and plat_jmp_go keep and restore the Win64 callee-saved registers, MXCSR and the x87 control word
themselves and validate nothing; Linux keeps setjmp and longjmp. Started with CFG forced on, the build before this
change ends with 0xc0000409 at the same log line and in --probe-kernel; this one reaches gameplay and passes the probe.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Earlier settings menus wrote free_cores = 1 under the label "Virtual core gate", which promised the gate. Without it a
thread that holds no virtual core reports its ideal core to GetCurrentProcessorNumber, so the game's job workers all
report core 0 and run its per-core code at once. On 1.2.1 two of them add the same per-core NVN control memory, which
retires the command handle the other just recorded, and its CallCommands fails at start (#212); on 1.4.3 the game
corrupts a heap in main+0x82e00 or hangs at the title menu. A player with such a totk.ini crashed at every start and
the menu no longer shows the row.
free_cores is no longer a setting: only TOTK_FREE_CORES in the environment lifts the gate, and a free_cores value in
totk.ini is logged as ignored. The kernel probe asks the kernel whether the gate is on.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The row was labelled "Virtual core gate" with the text "Lets only one thread run per virtual core, as on the
console", but switching it on wrote free_cores = 1, which lifts the gate. Without the gate guest threads run in
parallel on one virtual core, and TotK keeps its per-core data without locks: an Arc B580 player who turned it on
crashed at every start with "CallCommands: command handle ... is not a live recording" (#212). free_cores stays an
ini key for experiments; the log now says when it is set, and totk.ini.example warns that the game can crash.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Shared runtime code now goes through runtime/platform/platform.h, implemented by platform/win32.c and a new
platform/linux.c: futex locks, a userfaultfd and PAGEMAP_SCAN write watch, signal-based async preemption, our own
fiber switch, and a SIGSEGV handler for the thaw and crash hooks. The window, input, menu and software keyboard get
SDL3 back ends beside the Win32 ones, with the swapchain (gfx_present.c) and input merging (input.c) shared. SHA-256
replaces BCrypt, ELF builds get their own override sections, and the build tools gain Linux branches.
On Linux the selftest and the gfx-abi, astc, nvn and window probes pass. probe-vkmem still fails: imported guest
memory cannot be write-watched on Linux, which the shadow buffers in vk_memory.c will address.
Comments cited codes from local notes (port-lessons P1, backlog), task labels (T6c1-T6c3, M4), bare upstream commit
hashes and issue numbers, a file that no longer exists (nvn_api.c, now nvn_api_*.c), a generated file (main_0103.c)
and line numbers into upstream files that refs/ has moved past, so they pointed at unrelated code. Those now name the
file, function or project and say what the cited code does. Attribution of copied code keeps its pinned commits.
Corrected facts: TOTK_REPLAY_ASYNC defaults to 0, and the shader cache, pipeline cache and pipeline keys live next to
totk.exe, not in build/v121.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The generator emits a guest poll such as `ldr w9, [x19]; cmp w9, #1; b.eq` as a plain C load, and clang hoists it out
of the loop: the lock wait in f_7001fa0e2c compiled to `cmp; jne; jmp .`, so a thread that found the lock held spun
forever after its holder released it. A fight run hung this way in 3 of 13 launches on an RX 9070, with the UBO
snapshot on and off; gdb showed the thread on that `jmp` in every sample. The gate is an opaque call on every
back-edge of the 868 loops tools/spin_waits.py lists, so each pass reloads memory: the exe goes from 182 self-jumps to
148, and 144 of those are the game's own `b .` instructions. 8 of 8 fight runs then passed; tests/diff/func.py with
--patches passed 5470 cases on 878 functions, and the four probes passed on 1.4.3.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The FP helpers compared c->fpcr with a cached copy before every operation to resync MXCSR lazily. MXCSR now
follows FPCR.FZ at once: MSR FPCR calls rt_fpcr_sync, and so do rt_call (thread, fiber and host entry into guest
code), fiber resume (FIBER_FLAG_FLOAT_SWITCH fibers keep their own MXCSR) and the differential test harness per
case. op and vop only test FPCR.RMode for the slow path, and their redo check is one ordered-not-equal compare of
|r| with the smallest normal, the same NaN-or-smallest-normal set as before.
Hot guest code shrinks by about a quarter (132 functions holding half the guest cycles, 1.4.3); fight frame time
moves 1-3%, inside the run-to-run spread. lift, simd, func, atomic and flags_check pass on 1.4.3; simd.py fails
without the harness sync.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With TOTK_TRACE=sched, TOTK_CRIT=<lo>-<hi> records every state change and wake of the guest threads and every
present over those frames (runtime/kernel.c crit_add from acct() and wake(), crit_frame at the present) and writes
them to TOTK_CRIT_OUT at the last frame. tools/crit_path.py walks back from each present through the waits to the
thread whose signal ended them and splits the frame interval by thread and state; the sums equal the interval.
A 1.4.3 fight: with the replay on the submitting thread the path is 7.3 ms of replay on the render thread and 4.3 ms
of guest code; with TOTK_REPLAY_ASYNC=1 it is 10.1 ms of guest code through the fork-join of the main thread and five
workers, at the same frame interval.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Comments named the agent task (T1-T7, M2-M5, Task 2.x) that once owned each file or block, and pointed at local
notes the repository does not carry (backlog items, milestone plans, research notes). They now say what the code
does. gfx_stubs.c held weak stand-ins for functions that every build has defined for a long time.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
