[PATCH 2/2] ntdll: Move InterlockedCompareExchange128 support to winnt.h.
Puetz Kevin A
PuetzKevinA at JohnDeere.com
Fri Jul 31 12:46:07 CDT 2020
> Oh, I see, I didn't know it's already broken on aarch64. FWIW, I just wanted
> to fix a warning on clang msvcrt target and while doing that, I generalized the
> solution. We can wait with that for aarch64 solution.
Though what I was waiting on was to find out whether or was my problem
or somebody else's (i.e. would it still be an issue on our eventual BSP).
Which is, at least a bit, independent of whether wine needs a solution in general.
I probably should have at filed the bug anyway 😊
> Depending on -latomic may be problematic in PE builds. If I read libatomic
Mingw should have a -latomic too, it's the underlying runtime for the C++11 atomics
(but it just contains the C-API out-of-line implementations to fall back on
when there aren't appropriate intrinsics).
> source right, libatomic resorts to using lock in this case (pthread_mutex_lock
> or equivalent, depending on host).
Yes, that's what it does, which seemed equivalent to what wine had previously done,
and was easy to drop in as a workaround.
> We could probably just add a variant of affected RtlInterlocked*SList* functions
> that would use critical section instead of interlocked operations.
Yep. Or do what I think MS actually did, and implement the Header8 layout for when
you can't use double-pointer compare-and-exchange. They need that anyway,
(though maybe not anymore) since original amd64 CPUs don't have cmpxchg16b either.
I don't know the details on SLIST_HEADER::Header8 (presumably the same, just with
fewer bits in some of the fields), and there doesn't seem to be a lot of MSDN documentation
But here's some references I've dug up that at least mention it existed for such cases...
And obviously the Header8 struct in wine and reactos came from somewhere...
More information about the wine-devel