Horton

Re: [PATCH] Add native windows on arm64 support

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Dave Cramer <davecramer@postgres.rocks>
Cc: Andrew Dunstan <andrew@dunslane.net>, Michael Paquier <michael@paquier.xyz>, Anthony Roberts <anthony.roberts@linaro.org>, Daniel Gustafsson <daniel@yesql.se>, Lina Iyer <lina.iyer@linaro.org>, Mike Holmes <mike.holmes@linaro.org>, Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-02-13T17:52:17Z
Lists: pgsql-hackers 
Hi,

On 2024-02-13 12:49:33 -0500, Dave Cramer wrote:
> > I think I might have been on to something - if my human emulation of a
> > preprocessor isn't wrong, we'd end up with
> >
> > #define S_UNLOCK(lock)  \
> >         do { _ReadWriteBarrier(); (*(lock)) = 0; } while (0)
> >
> > on msvc + arm. And that's entirely insufficient - _ReadWriteBarrier() just
> > limits *compiler* level reordering, not CPU level reordering.  I think it's
> > even insufficient on x86[-64], but it's definitely insufficient on arm.
> >
> In fact ReadWriteBarrier has been deprecated _ReadWriteBarrier | Microsoft
> Learn
> <https://learn.microsoft.com/en-us/cpp/intrinsics/readwritebarrier?view=msvc-170>

I'd just ignore that, that's just pushing towards more modern stuff that's
more applicable to C++ than C.


> I did try using atomic_thread_fence as per atomic_thread_fence -
> cppreference.com
> <https://en.cppreference.com/w/c/atomic/atomic_thread_fence>

The semantics of atomic_thread_fence are, uh, very odd.  I'd just use
MemoryBarrier().

Greetings,

Andres Freund

Commits

  1. MSVC: Support building for AArch64.

  2. Remove "#ifdef WIN32" guards from src/port/win32*.c

  3. Adjust XML test case to avoid unstable behavior.

  4. Enable RandomizedBaseAddress (ASLR) on Windows with MSVC builds