Subject: [PATCH] Add native windows on arm64 support

From: Niyas Sait <[email-masked]>
Date: Wed, 23 Feb 2022 10:09:36 +0000

Hello,

I have created a patch that adds support for building Postgres for the
windows/arm64 platform using the MSVC toolchain. Following changes have
been included

1. Extend MSVC scripts to handle ARM64 platform.
2. Add arm64 definition of spin_delay function.
3. Exclude arm_acle.h import with MSVC compiler.

Compilation steps are consistent and similar to other windows platforms.

The change has been tested on windows/x86_64 and windows/arm64 and all
regression tests passes on both platforms.

Thanks,
Niyas

---

From: Thomas Munro <[email-masked]>
Date: Sat, 19 Mar 2022 09:50:06 +1300

On Wed, Feb 23, 2022 at 11:09 PM Niyas Sait <[email-masked]> wrote:
> I have created a patch that adds support for building Postgres for the windows/arm64 platform using the MSVC toolchain. Following changes have been included
>
> The change has been tested on windows/x86_64 and windows/arm64 and all regression tests passes on both platforms.

+    # arm64 linker only supports dynamic base address
+    my $cfgrandbaseaddress = $self->{platform} eq 'ARM64' ? 'true' : 'false';
...
+      <RandomizedBaseAddress>$cfgrandbaseaddress</RandomizedBaseAddress>

Does that mean that you can't turn off ASLR on this arch?  Does it
cause random backend failures due to inability to map shared memory at
the expected address?  Our experience with EXEC_BACKEND on various
Unix systems tells us that you have to turn off ASLR if you want 100%
success rate on starting backends, but I guess it depends on the
details of how the randomisation is done.

Any interest in providing a build farm animal, so that we could know
that this works?

---

From: Niyas Sait <[email-masked]>
Date: Tue, 22 Mar 2022 09:37:46 +0000

Thanks, Thomas for reviewing the patch!

Yes, we cannot turn off ASLR for Arm64 targets with MSVC. I haven't seen
any issues so far on win/arm64 with this option turned off. I guess it
should be okay. If we really need ASLR turned off, then I guess might have
to use clang.

Yes, we could look into providing a build machine. Do you have any
reference to what the CI system looks like now for PostgresSQL and how to
add new workers etc.?

Niyas

---

From: Julien Rouhaud <[email-masked]>
Date: Tue, 22 Mar 2022 18:30:11 +0800

Hi,

Please don't top-post here.  See
https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics.

> reference to what the CI system looks like now for PostgresSQL and how to

It's all documented at
https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto.

---

From: Thomas Munro <[email-masked]>
Date: Wed, 23 Mar 2022 16:30:58 +1300

> https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto.

It seems likely there will be more and more Windows/ARM users, so yeah
having a machine to test that combination would be great.  I wonder if
ASLR isn't breaking for you by good luck only...

---

From: Andres Freund <[email-masked]>
Date: Wed, 23 Mar 2022 18:15:31 -0700

Hi,

> ASLR isn't breaking for you by good luck only...

I think we've generally seen the ASLR issue become less prominent on
windows. Whether that's because of the silent retries we added, or because
just about everyone moved to 64bit windows / PG, I don't know. I'd guess both,
with 64bit being the larger influence.

Wonder if it's worth adding some debug logging to the retry code and stop
disabling ASLR on 64bit windows... It's imo pretty crazy that we loop up to
100 times in internal_forkexec() around CreateProcess() &&
pgwin32_ReserveSharedMemoryRegion() without, as far as I can see, a single
debug message.

I don't think we can infer too much about the failure rate on windows from the
!windows EXEC_BACKEND rates. The two internal_forkexec() implementations
behaves just too differently.

Greetings,

Andres Freund

---

From: Thomas Munro <[email-masked]>
Date: Fri, 25 Mar 2022 11:38:44 +1300

> pgwin32_ReserveSharedMemoryRegion() without, as far as I can see, a single

Yeah.  I think we should commit this patch, but decree that
Windows/aarch64 support is experimental only for now.  That allows a
build farm animal to be set up.  Then we add a bit of extra logging
and see how it does running our test suite over time and learn more.

---

From: Michael Paquier <[email-masked]>
Date: Thu, 7 Apr 2022 15:36:19 +0900

> and see how it does running our test suite over time and learn more.

I don't have such a setup so my testing capabilities are limited.
Does anybody have one?  I think that we could be flexible for this
patch, even after feature freeze as it introduces something entirely
new without impacting the existing code.  The patch has been moved to
the next CF for now.
--
Michael

---

From: Tom Lane <[email-masked]>
Date: Thu, 07 Apr 2022 09:40:43 -0400

> new without impacting the existing code.  The patch has been moved to

I dunno, the lack of any in-house capability for this makes me very
nervous.  If it causes problems down the road, how will we debug it?
So it seems like the sort of patch to put in at the beginning of a
development cycle, not post-feature-freeze.

			regards, tom lane

---

From: Daniel Gustafsson <[email-masked]>
Date: Thu, 7 Apr 2022 16:55:27 +0200

> On 7 Apr 2022, at 15:40, Tom Lane <[email-masked]> wrote:
> 

If those with an interest in such platform support cannot spare the cycles to
at least run a buildfarm member, then it seems a stretch for us to maintain
such support with any confidence.

> development cycle, not post-feature-freeze.

+1

--
Daniel Gustafsson		https://vmware.com/

---

From: Andres Freund <[email-masked]>
Date: Thu, 7 Apr 2022 10:22:58 -0700

Hi,

On 2022-04-07 09:40:43 -0400, Tom Lane wrote:
> If it causes problems down the road, how will we debug it?

If what causes problems down the road? Afaics the patch doesn't change
anything outside of windows-on-arm, so it shouldn't cause any breakage we care
about until we get a buildfarm animal.

We've traditionally been somewhat relaxed about adding support for new

> development cycle, not post-feature-freeze.

There doesn't seem to be a great urgency, and there's plenty stuff going on
right now. I can see us merging it post branching off, and then backpatching
it a bit later?

Greetings,

Andres Freund