Wow64/arm64ec resets MXCSR on signal

[Sonicadvance1]

These always reset MXCSR on signal, which means that games using asserts will lose the DAZ bit. Which they tend to set once and then just keep enabled. Hasn't bitten us yet but will likely occur.

[bylaws]

are you sure this happens for arm64ec? It should work

[Sonicadvance1]

I can definitely see the code not handling mxcsr where it is saving and restoring the rest of XMM state. We just don't have any wine unittests to show it as an issue.

[bylaws]

I can definitely see the code not handling mxcsr where it is saving and restoring the rest of XMM state. We just don't have any wine unittests to show it as an issue.

Yeah that's expected, wine should do for us

[Sonicadvance1]

How does that work? Does it have FXSave and FXRStor trampolines generation somewhere? That's the only way it could pull that data from our InternalThreadState object otherwise.

[bylaws]

How does that work? Does it have FXSave and FXRStor trampolines generation somewhere? That's the only way it could pull that data from our InternalThreadState object otherwise.

Fpcr is just restored to prior state after a signal resumes

[Sonicadvance1]

Sure, FPCR I don't have an issue with. MXCSR is a different register.

[Sonicadvance1]

Also, if FPCR is getting restored but MXCSR isn't then we're now tearing the view between the two.

[bylaws]

Sure, FPCR I don't have an issue with. MXCSR is a different register.

Right but this is where DAZ is set so the main issue described isn't possible. Though you're right about tearing