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...
https://docs.microsoft.com/en-us/windows/win32/sync/interlocked-singly-linke... https://devblogs.microsoft.com/oldnewthing/20110819-00/?p=9853 https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms... https://cbloomrants.blogspot.com/2010/05/05-29-10-lock-free-in-x64.html
Thanks,
Jacek