XSAVE-related segfaults observed under wine

[Pip Cet]

"Jeremy Drake" <cygwin@jdrake.com> writes:

> On Fri, 27 Jun 2025, Corinna Vinschen via Cygwin wrote:
>
>> Hi Pip,
>>
>> On Jun 27 14:41, Pip Cet via Cygwin wrote:
>> > My suggested fix is to align the value in %rbx to the next 64-byte
>> > multiple after the "cpuid" instruction is executed, by performing the
>> > assembler equivalent of $rbx += 63; $rbx &= -64; I tried this:
>> >
>> > diff --git a/winsup/cygwin/scripts/gendef b/winsup/cygwin/scripts/gendef
>> > index 861a2405b..d681fde3f 100755
>> > --- a/winsup/cygwin/scripts/gendef
>> > +++ b/winsup/cygwin/scripts/gendef
>> > @@ -232,6 +232,8 @@ sigdelayed:
>> >  	movl	\$0x0d,%eax
>> >  	xorl	%ecx,%ecx
>> >  	cpuid	# get necessary space for xsave
>> > +	addq	\$63, %rbx
>> > +	andq	\$-64, %rbx # align to next 64-byte multiple
>>
>> what about a oneliner instead by just aligning rsp?  As in
>>
>> >  	movq	%rbx,%rcx
>> >  	addq	\$0x48,%rbx # 0x18 for alignment, 0x30 for additional space
>
> If aligning via andq, does the 0x18 "for alignment" still need to be
> included?

If we align %rsp, as Corinna suggested, we don't need the 0x18.

If we do what my patch did and align %rbx, we do need to subtract 0x18,
because that's the amount by which our stack pointer is misaligned (it
was aligned to 64 bytes, then we pushed 13 8-byte registers).

Technically, instead of aligning %rbx to a multiple of 64 and adding
0x48, we could round it up to the next integer that's congruent to 0x18
modulo 0x40 and add 0x30, saving 64 bytes of stack space on some CPUs
(including, I believe, both of my PKU-enabled CPUs).

This may be a sour grapes scenario, but using xsavec or clearing only
part of the xsave64 area (the current code clears all of it) would be
other optimizations that might have more of an impact.

Pip