DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 55RKlk7S1581722 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 55RKlk7S1581722 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=sFUrhGwU X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6CC46385C6D5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1751057264; bh=PiJf/0/W9SIHsn7+wyuzsauQyQ/GC1alyoNjt/aj0r4=; h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=sFUrhGwU8vF0G+dNNWncUJetKkGPgf57YNMYU26l6jpqp9/GY6XfoHLE2jE9ijPEH bfeyrK8Q9Jz7mwJQuHmky/OMENPBqbt37X+oUliJ9aKDEde54faQrEiw27PoIJ7afI KtYXig8LQjzXZy4dxh2lBxZsS7tbomfg/4k+tkvA= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 449023858408 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 449023858408 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1751057239; cv=none; b=oG6wsw4mZ1/xXOOcdpMoVB2nebFEwlfqnVkGan9L9M66S1zVjwndL7ozGc8ACeUi82j3FJmyxYUCYcJHvRZ8ZsTnz7i6yLaJQPCQo+yNa9iNFbpZLHuXGIJ2SKAtNz7g0Q2/2NHAsZw7UHvVF3Vn0BW5h4/jXHdaPBei1KJuAxA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1751057239; c=relaxed/simple; bh=z4+CZhxgnGU9c1RtJdN2XF5nDoyTBcHmhw3O6ic8o8U=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=uX0s27nKB3jKkpotRNcgqy3EInasz/EIAJwg4Vgl43+Wx7bJMm7bzrBFDc9Pdu6Mx0YeNGEpmLEH6z1Db6gMT7tmi9BM3bJxhhwgLTQeS9G7mmYW2EnYpd7wy2gVQH8txXQJwemkEALZRUPhaDQPhQn62Z3PK02BIfmgiIO7vLo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 449023858408 Date: Fri, 27 Jun 2025 20:47:11 +0000 To: Jeremy Drake Cc: Corinna Vinschen via Cygwin Subject: Re: XSAVE-related segfaults observed under wine Message-ID: <87tt403oac.fsf@protonmail.com> In-Reply-To: References: <87bjq9457k DOT fsf AT protonmail DOT com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 3a4855ffab35db9c520bb56ad13494cf636a8ac8 MIME-Version: 1.0 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Pip Cet via Cygwin Reply-To: Pip Cet Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" "Jeremy Drake" 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple