[PATCH 13/18] ntdll: Use syscall frame for YMM context in x86_64 NtGetContextThread.

Jacek Caban jacek at codeweavers.com
Fri Jan 22 12:10:11 CST 2021


On 22.01.2021 19:01, Paul Gofman wrote:
> On 1/22/21 20:51, Jacek Caban wrote:
>> On 22.01.2021 18:44, Paul Gofman wrote:
>>>> What seems to be more interesting is xsaveopt, which I think could
>>>> make a difference. That would, however, need xsave are to be at
>>>> constant address. I've been thinking about storing it next to TEB, but
>>>> we can't do that as long as winsock is called on signal stack, so I
>>>> left experimenting with it for the future.
>>>>
>>> xsavec also performs an optimization (doesn't save the xstate in initial
>>> state),
>>
>>
>> As I said, xsave already does that optimization, there is no need for 
>> xsavec for that.
>>
> Are you sure? As I read the docs, there is no mention of xsave 
> avoiding any saves (e. g., [1], [2]), and I probably even tested that 
> (well, not 100% sure now_ xsave zeros the data while xsavec 
> (expectedly) does not.:
>
> From 2 (savec):
>
> TO_BE_SAVED ← RFBM AND XINUSE;
>
> From 1:
>
> Only "RFBM ← XCR0 AND EDX:EAX;" is used as a flag controlling whether 
> save is performed or not.
>

Oh, right, I was confused by the fact that it does not set the bit in mask:

XSTATE_BV field in XSAVE header ← (OLD_BV AND ~RFBM) OR (XINUSE AND RFBM);


So it may be interesting if xsaveopt doesn't work out.


Jacek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210122/ae145d02/attachment.htm>


More information about the wine-devel mailing list