New subject: [Bug 60504] x86_64: xmm6-xmm15 come back stale from a system call made while all xmm registers are zero

Oct. 15, 2026

      http://bugs.winehq.org/show_bug.cgi?id=60504

            Bug ID: 60504
           Summary: x86_64: xmm6-xmm15 come back stale from a system call
                    made while all xmm registers are zero
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ntdll
          Assignee: wine-bugs@list.winehq.org
          Reporter: lorenzvdv@proton.me
  Target Milestone: ---
      Distribution: ---

Created attachment 82362
  --> http://bugs.winehq.org/attachment.cgi?id=82362
C code to reproduce the bug

On x86_64, a system call made while every xmm register is zero (and MXCSR is at
its default, 0x1F80) returns with xmm6-xmm15 holding the values they had at an
*earlier* system call. xmm6-xmm15 are callee-saved in the Win64 ABI, so
compiled code that keeps a value there across a call into the system sees it
change.

The attached program sets xmm6-xmm15 to a pattern and calls Sleep(0). It then
zeroes xmm0-xmm15 and calls Sleep(0) again. After the second call, xmm6-xmm15
should still be zero. Under Wine they hold the pattern from before the first
call:

```
  xmm6 after the second Sleep: {0x0000000000000006, 0x0000000000000100}
MXCSR at its default: xmm6-xmm15 changed across Sleep(0) (expected: all zero)
MXCSR.PE set: ok, xmm6-xmm15 zero
```

All ten registers are affected, not just xmm6. Setting MXCSR's sticky precision
flag (PE, 0x20) beforehand makes the problem go away; nothing else in the
program changes.

**Likely cause (a guess):** with all xmm registers zero and MXCSR at its
default, the SSE state is in its initial configuration. XSAVEOPT / XSAVEC /
XSAVES then skip writing it (XSTATE_BV bit 1 clear), but the registers still
seem to be restored from the save area's legacy region, which holds what an
earlier call left there. Setting MXCSR.PE keeps the state out of its initial
configuration, so it is always saved. This is the same code as bug 58335
(xsave64 with a zero mask in `__wine_syscall_dispatcher`, a skipped save
followed by a restore), but this machine has AVX/AVX-512 and the mask is not
zero.

**How it showed up:** a compiled program kept a zero in xmm6 across calls. A
memset that stores 16 bytes at a time left xmm0/xmm1 zero, so every xmm
register happened to be zero at the next system call. The zero in xmm6 came
back as an unrelated value from an earlier call, and a socket buffer's offsets
were overwritten with it. The program works on Linux, where the system V ABI
has no callee-saved xmm registers.

**Steps to reproduce:**

```
printf 'LIBRARY
kernel32.dll\nEXPORTS\nSleep\nGetStdHandle\nWriteFile\nExitProcess\n' >
kernel32.def
llvm-dlltool -m i386:x86-64 -d kernel32.def -l kernel32.lib
clang --target=x86_64-pc-windows-msvc -O1 -ffreestanding -fno-builtin
-fno-stack-protector -c repro.c -o repro.obj
lld-link /entry:start /subsystem:console /nodefaultlib repro.obj kernel32.lib
/out:repro.exe
wine repro.exe
```

The attached repro.c is the only file needed. The program needs no C runtime.
With mingw, `x86_64-w64-mingw32-gcc -O1 -nostdlib -e start repro.c -lkernel32
-o repro.exe` should do the same (untested here).

The exit status is 1 when the registers came back changed and 0 when they did
not.

**Expected:** xmm6-xmm15 are zero after the second Sleep(0) (as on Windows).

**Actual:** they hold the values from before the first Sleep(0).

**System:**
- Wine 11.19 (CachyOS package 11.19-1.1, not yet checked with an upstream
build)
- Linux 7.2.6-1-cachyos
- AMD Ryzen 5 7600X (Zen 4: AVX-512, XSAVEOPT, XSAVEC, XSAVES)
- 64-bit prefix

The same happens with SwitchToThread() and recv() in place of Sleep(0), on the
main thread and on other threads.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 60504] New: x86_64: xmm6-xmm15 come back stale from a system call made while all xmm registers are zero

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

tags

participants (1)