Subject: Re: [PATCH] Add native windows on arm64 support

From: Michael Paquier <[email-masked]>
Date: Sat, 6 May 2023 12:09:22 +0900

On Tue, May 02, 2023 at 08:51:09AM +0100, Niyas Sait wrote:
> I've attached a new version (v8) to fix the above indentation issue.
> 
> Could someone please help with the review ?

Seeing how simple this has become, I would be really tempted to get
that applied, especially if there's a buildfarm machine able to follow
up..  On the one hand, we are in a stability period for v16, so it may
not be the best moment ever.  On the other hand, waiting one more year
sounds like a waste for a patch that just adds new code paths.

RMT members, any thoughts?
--
Michael

---

From: Tom Lane <[email-masked]>
Date: Sat, 06 May 2023 00:35:40 -0400

> sounds like a waste for a patch that just adds new code paths.

Indeed, there's not much in this patch ... but it's impossible to see
how "run on an entirely new platform" isn't a new feature.  Moreover,
it's a platform that very few of us will have any ability to support
or debug for.  I can't see how it's a good idea to shove this in
post-feature-freeze.  Let's plan to push it in when v17 opens.

			regards, tom lane

---

From: Michael Paquier <[email-masked]>
Date: Sun, 7 May 2023 09:37:50 +0900

> post-feature-freeze.  Let's plan to push it in when v17 opens.

Fine by me.  I have added an entry in the CF app to remember about
this stuff as there was nothing present yet:
https://commitfest.postgresql.org/43/4309/
--
Michael

---

From: Andres Freund <[email-masked]>
Date: Mon, 8 May 2023 12:17:31 -0700

Hi,

> post-feature-freeze.  Let's plan to push it in when v17 opens.

I don't really have feelings either way - but haven't we gone further and even
backpatched things like spinlock support for new arches in the past?

Greetings,

Andres Freund

---

From: Tom Lane <[email-masked]>
Date: Mon, 08 May 2023 15:58:41 -0400

> backpatched things like spinlock support for new arches in the past?

Mmmm ... don't really think those cases were comparable.  We weren't
adding support for a whole new OS.  Now, you might argue that Windows
on arm64 will be just like Windows on x86_64, but I think the jury
is still out on that.  Microsoft was so Intel-only for so many years
that I bet they've had to change quite a bit to make it go on ARM.

Also, the cases of back-patched spinlock support that I can find
in the last few years were pretty low-risk.  I'll grant that
c32fcac56 was a bit blue-sky because hardly anybody had RISC-V
at that point, but by the same token anybody relying on it at the
time would be dealing with a beta-grade OS too.  On the other hand,
1c72d82c2 was immediately testable in the buildfarm, and f3bd00c01
was importing code already verified by our OpenBSD packagers.

As I said upthread, this seems like something to put in at the
beginning of a dev cycle, not post-feature-freeze.

			regards, tom lane

---

From: Andrew Dunstan <[email-masked]>
Date: Wed, 10 May 2023 09:24:39 -0400

On 2023-05-08 Mo 15:58, Tom Lane wrote:
> Andres Freund<[email-masked]>  writes:

We will definitely want buildfarm support. I don't have such a machine 
and am not likely to have one any time soon. I do run drongo and 
fairywren on an EC2 instance, but AWS doesn't seem to have support for 
Windows on ARM. Maybe it's available on Azure (maybe then some of our 
colleagues working at Microsoft could arrange such a beast for me to set 
up potential buildfarm animal, or else run one themselves.)

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

---

From: Michael Paquier <[email-masked]>
Date: Thu, 11 May 2023 08:34:29 +0900

On Wed, May 10, 2023 at 09:24:39AM -0400, Andrew Dunstan wrote:
> We will definitely want buildfarm support. I don't have such a machine and
> am not likely to have one any time soon. I do run drongo and fairywren on an
> EC2 instance, but AWS doesn't seem to have support for Windows on ARM. Maybe
> it's available on Azure (maybe then some of our colleagues working at
> Microsoft could arrange such a beast for me to set up potential buildfarm
> animal, or else run one themselves.)

Unfortunately AWS does not offer ARM on Windows with an EC2, that's
something I have also looked at setting up :/

Anyway, Niyat has mentioned me that he was working on that, but it
seems that it was off-list.  Niyat, could you confirm this part?
--
Michael

---

From: Thomas Munro <[email-masked]>
Date: Thu, 11 May 2023 12:17:25 +1200

> something I have also looked at setting up :/

Azure does have an image "Microsoft Windows 11 Preview arm64" to run
on Ampere CPUs, which says it's a pre-release version intended for
validation, which sounds approximately like what we want.  I will try
to find out more.

---

From: Michael Paquier <[email-masked]>
Date: Thu, 11 May 2023 13:19:54 +0900

> validation, which sounds approximately like what we want.  I will try

Interesting.  Thanks for mentioning it.
--
Michael

---

From: Niyas Sait <[email-masked]>
Date: Thu, 11 May 2023 08:57:57 +0100

> seems that it was off-list.  Niyat, could you confirm this part?

If we have Azure VM credits, we could use that to deploy buildfarm machines.

Otherwise, I can try to allocate a machine from Linaro Windows Lab for 
the buildbot.

-- 
Niyas

---

From: Niyas Sait <[email-masked]>
Date: Wed, 14 Jun 2023 13:25:17 +0100

Hello,

Just wanted to give a heads up that I am moving to a new role outside 
Linaro and as a result wouldn't be able to continue contributing.

Anthony Roberts from Linaro is going to support the enablement work.

-- 
Niyas

---

From: Michael Paquier <[email-masked]>
Date: Tue, 4 Jul 2023 16:34:36 +0900

> Interesting.  Thanks for mentioning it.

Now that v17 is open, I was looking at v8 posted at [1] and I don't
have much more to add about it.  The problem about the lack of
buildfarm machine is still annoying, but I don't see a reason not to
move forward and let people play with this stuff on HEAD.  At least
that would be progress.  Any thoughts?

Thomas, what's the state of ARM support for Windows on Azure?  Is that
still in preview?

[1]: https://www.postgresql.org/message-id/dbee741f-b9b7-a0d5-1b1b-f9b532bb6f56%40linaro.org
--
Michael

---

From: Anthony Roberts <[email-masked]>
Date: Thu, 17 Aug 2023 09:41:44 +0100

Hi All,

Just following up on this, has there been any movement?

I did see another message go into the thread here with no reply: 
https://www.postgresql.org/message-id/ZKPLjLjIjwN2lxkg%40paquier.xyz

Thanks,
Anthony

---

From: Michael Paquier <[email-masked]>
Date: Fri, 18 Aug 2023 07:28:04 +0900

> https://www.postgresql.org/message-id/ZKPLjLjIjwN2lxkg%40paquier.xyz

I don't have an environment to test the patch, but I don't object to
it per se.  However, I don't really want to move forward completely
blindly as well in the long-term.

As mentioned to Niyas, could it be possible to provide to the
community a buildfarm machine that would be able to test this
environment?  I am not sure what's your status on that.  Perhaps this
is already set up and you are just waiting for the patch to be merged?
--
Michael

---

From: Anthony Roberts <[email-masked]>
Date: Fri, 25 Aug 2023 10:40:39 +0100

Hi,

Which of these are you looking for us to provide:

* A machine for you to directly access (via a VPN)
* A machine we just run a worker script on that automatically picks up 
the builds as required
* Us to do downstream CI

All are possible, but preferably not option 1, as it would mean straight 
up pulling out a machine from our build farm, and it has to go through 
all sorts of approvals internally. If it's the only way forward I can 
kick it up the chain though.

Option 2 and 3 are ones we do for various other projects (ie. 2 - CMake, 
3 - OpenSSL)

Thanks,
Anthony

---

From: Michael Paquier <[email-masked]>
Date: Fri, 25 Aug 2023 19:17:27 +0900

On Fri, Aug 25, 2023 at 10:40:39AM +0100, Anthony Roberts wrote:
> * A machine we just run a worker script on that automatically picks up the
> builds as required
> * Us to do downstream CI
> 
> All are possible, but preferably not option 1, as it would mean straight up
> pulling out a machine from our build farm, and it has to go through all
> sorts of approvals internally. If it's the only way forward I can kick it up
> the chain though.
> 
> Option 2 and 3 are ones we do for various other projects (ie. 2 - CMake, 3 -
> OpenSSL)

The community has its own CI facility.  Here is a link of how to set
up a machine:
https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto

And all the results are published by the maintainers of the machines
on a periodic basis where the buildfarm client code is set:
https://buildfarm.postgresql.org/cgi-bin/show_status.pl

The final result would be for you to maintain the machine so as we are
able to see if anything breaks with it.  Adding extra dependencies to
the build like OpenSSL would be nice, but based on the contents of the
patch to add this port that does not seem mandatory to me, either.

Once the machine is ready, you will need to request a buildfarm
machine name and a key to be able to begin publishing the reports of
the builds to the community buildfarm.  Once the machine is ready to
go, just let me know and I'd be OK to merge the patch (I still want to
do a final review of it in case I've missed something, but I can move
on with that before the buildfarm machine is set up).
--
Michael

---

From: Anthony Roberts <[email-masked]>
Date: Fri, 25 Aug 2023 11:34:18 +0100

Thanks for the link - that looks basically the same as what we do for 
CMake (option 2), so should be relatively easy.

I will have a chat to relevant people about setting a machine up 
properly for it.

Thanks,
Anthony

---

From: Daniel Gustafsson <[email-masked]>
Date: Fri, 25 Aug 2023 13:48:21 +0200

> On 25 Aug 2023, at 11:40, Anthony Roberts <[email-masked]> wrote:

> * A machine for you to directly access (via a VPN)

That could be very helpful to provide to developers who are trying to debug
very wicked bugs which requires access for analysis.  Such things are on a case
by case basis of course at your discretion, but it would most likely be very
appreciated when/if the need exists.

> * A machine we just run a worker script on that automatically picks up the builds as required

This sounds like what we have for the buildfarm, where machines independently
builds the branches from the Git repo by using the buildfarm client as worker.

> * Us to do downstream CI

This sounds like the CFBot, where we (currently) use Cirrus with our own
workers for building and testing the patches which are being worked on.

	http://cfbot.cputube.org/

Both the two latter options are very helpful for the community, and serve two
distincly different purposes.  Option 2 is required for a platform to be
considered supported whereas option 3 assists developers in being proactive
rather than just reactive.

--
Daniel Gustafsson

---

From: Anthony Roberts <[email-masked]>
Date: Wed, 30 Aug 2023 16:12:16 +0100

Hi,

Just a follow-up: having spoken to the relevant people, sadly, right now,
we do not have the capacity to be pulling machines out of our day-to-day CI
tasks to dedicate to specific projects.

I can, however, offer a few alternatives:

1. If you have capacity on your linux x64 machines, it is possible to
emulate WoA, and run tests that way:
https://www.linaro.org/blog/emulate-windows-on-arm/
This is something that works well for projects that we have contributed it
to (ie, sse2neon uses it via github actions) - if you run into any issues
with this, we are able to try and fix them on our side, as likely more than
postgres would benefit.

2. If there is any scope for it on your side at all, a Samsung Galaxy Book
Go 14" can be had from ebay for ~£140.
Understandably, this might not be an option for you.

If it helps, if this is merged, we do have the possibility of running our
own downstream CI builds nightly for the tip of your main branch here:
https://gitlab.com/Linaro/windowsonarm/nightly
This is something we do for a few projects that do not have full upstream
CI.

Thanks,
Anthony

On Fri, 25 Aug 2023 at 11:34, Anthony Roberts <[email-masked]>
wrote:

> the

---

From: Michael Paquier <[email-masked]>
Date: Thu, 31 Aug 2023 13:22:16 +0900

> tasks to dedicate to specific projects.

Okay, thanks for letting us know.

> This is something we do for a few projects that do not have full upstream

Honestly, I am not sure how to proceed here.  Having something in the
buildfarm is necessary IMO, because this is the central place that
community members look at when it comes to monitoring the stability of
a patch committed.

Any opinions from the others?
--
Michael

---

From: Tom Lane <[email-masked]>
Date: Thu, 31 Aug 2023 00:44:07 -0400

> Okay, thanks for letting us know.

Too bad.

> Any opinions from the others?

I agree.  I'm really uncomfortable with claiming support for
Windows-on-ARM if we don't have a buildfarm member testing it.
For other platforms that have a track record of multiple
hardware support, it might not be a stretch ... but Windows was
so resolutely Intel-only for so long that "it works on ARM" is
a proposition that I won't trust without hard evidence.  There
are too many bits of that system that might not have gotten the
word yet, or at least not gotten sufficient testing.

My vote for this is we don't commit without a buildfarm member.

(As a comparison point, I'd still be unsure about our support
for macOS-on-ARM if we didn't have buildfarm support for that.
That exists, and is being paid for out of my own pocket.
I do not have much sympathy for a corporation that claims
it can't afford to support one measly buildfarm animal.)

			regards, tom lane

---

From: Thomas Munro <[email-masked]>
Date: Thu, 31 Aug 2023 16:57:05 +1200

> community members look at when it comes to monitoring the stability of

It's tricky, because usually the org that wants the thing to work
supplies the thing, and I personally think that provides a meaningful
"demand" signal too.  For example, we have external Solaris
representation, but no users of AIX represented at this point, and I
consider that to be quite interesting information.  Plenty of people
want PG to work well on their OS or architecture.

But, supposing Azure credits were suddenly available (just between
you, me and the mailing list, I heard that this should be imminent as
some kind of grant to PG US, as a result of the Cirrus thing), do we
have a Windows-savvy volunteer to feed and water an animal?  I feel
like this case is inevitable anyway because people in our own
community are probably going to be using Windows ARM laptops sooner or
later...

---

From: Tom Lane <[email-masked]>
Date: Thu, 31 Aug 2023 01:06:53 -0400

> community are probably going to be using Windows ARM laptops sooner or

That's a good point.  The hardware resources to support a buildfarm
animal are really pretty trivial these days.  What is important is
an animal owner who is willing to help chase down problems when they
arise.

Maybe we just need to wait for some community members to acquire
those laptops.

			regards, tom lane

---

From: Michael Paquier <[email-masked]>
Date: Thu, 31 Aug 2023 14:33:56 +0900

> an animal owner who is willing to help chase down problems when they

Unfortunately I don't see myself running that at home.  It is too hot
and humid in Summer so the machine would not last.  Something in the
cloud would be OK for me, but AWS has no option for a Windows host
with ARM yet.
--
Michael

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 13 Sep 2023 21:12:46 +0200

> My vote for this is we don't commit without a buildfarm member.

I think we can have a multi-tiered approach, where we can commit support 
but consider it experimental until we have buildfarm coverage.

---

From: Daniel Gustafsson <[email-masked]>
Date: Thu, 14 Sep 2023 11:39:20 +0200

> On 13 Sep 2023, at 21:12, Peter Eisentraut <[email-masked]> wrote:
> 
> I think we can have a multi-tiered approach, where we can commit support but consider it experimental until we have buildfarm coverage.

If it's experimental it should probably be behind an opt-in flag in
autoconf/meson, or be reverted by the time REL_17_STABLE branches unless
coverage has materialized by then.

--
Daniel Gustafsson

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 19 Sep 2023 10:33:48 +0200

> coverage has materialized by then.

The author's email is bouncing now, due to job change, so it's unlikely 
we will see any progress on this anymore.  I am setting it to returned 
with feedback.

---

From: Anthony Roberts <[email-masked]>
Date: Tue, 19 Sep 2023 13:35:17 +0100

Hi,

This was covered earlier in the thread - I have taken this on in Niyas' 
stead.

Was there an explicit request for something there? I was under the 
impression that this was all just suggestion/theory at the moment.

Thanks,
Anthony

On 19/09/2023 09:33, Peter Eisentraut wrote:
>>> I think we can have a multi-tiered approach, where we can commit 
>>> support but consider it experimental until we have buildfarm coverage.
>>
> The author's email is bouncing now, due to job change, so it's 
> unlikely we will see any progress on this anymore.  I am setting it to 
> returned with feedback.
>

---

From: Michael Paquier <[email-masked]>
Date: Wed, 20 Sep 2023 07:59:53 +0900

> impression that this was all just suggestion/theory at the moment.

Yes.  The addition of a buildfarm member registered into the community
facilities, so as it is possible to provide back to developers dynamic
feedback to the new configuration setup you would like to see
supported in PostgreSQL.  This has been mentioned a few times on this
thread, around these places:
https://www.postgresql.org/message-id/20220322103011.i6z2tuj4hle23wgx@jrouhaud
https://www.postgresql.org/message-id/[email-masked]
https://www.postgresql.org/message-id/[email-masked]
--
Michael

---

From: Dave Cramer <[email-masked]>
Date: Tue, 23 Jan 2024 08:46:37 -0500

> https://www.postgresql.org/message-id/[email-masked]

The attached patch works with v17. I will work on getting a buildfarm
animal up shortly

---

From: Dave Cramer <[email-masked]>
Date: Tue, 23 Jan 2024 16:13:05 -0500

> The attached patch works with v17. I will work on getting a buildfarm
I can build using meson manually, but for some reason building with the
buildfarm fails.

I'm not sure which files to attach to this to help. Andrew, what files do
you need ?

Dave

---

From: Michael Paquier <[email-masked]>
Date: Wed, 24 Jan 2024 08:32:08 +0900

>> The attached patch works with v17. I will work on getting a buildfarm

Thanks for doing that!

> I'm not sure which files to attach to this to help. Andrew, what files do

Probably build.ninja and the contents of meson-logs/ would offer
enough information?
--
Michael

---

From: Dave Cramer <[email-masked]>
Date: Wed, 24 Jan 2024 06:45:21 -0500

> Probably build.ninja and the contents of meson-logs/ would offer

I managed to get it to build the vcvarsall arch needs to be x64. I need to
add some options, but the patch above needs to be applied to build it.

Dave

---

From: Michael Paquier <[email-masked]>
Date: Thu, 25 Jan 2024 09:02:30 +0900

> add some options, but the patch above needs to be applied to build it.

Nice.  If I may ask, what kind of host and/or configuration have you
used to reach a state where the code can be compiled and run tests
with meson?  If you have found specific steps, it may be a good thing
to document that on the wiki, say around [1].

Perhaps you have not included TAP?  It may be fine in terms of runtime
checks and coverage.

[1]: https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Running_on_Windows
--
Michael

---

From: Dave Cramer <[email-masked]>
Date: Thu, 25 Jan 2024 08:31:07 -0500

> to document that on the wiki, say around [1].

I am running a mac-mini M2 with parallels running windows pro 11
The only thing required is this patch. Running in a native developer
prompt

meson setup build --prefix=c:\postgres
cd build
ninja
ninja install
ninja test

all run without errors
I also have buildfarm running and will run that today

Dave

> Perhaps you have not included TAP?  It may be fine in terms of runtime

Does TAP have to be explicitly added to the meson build ?

Dave

---

From: Dave Cramer <[email-masked]>
Date: Thu, 25 Jan 2024 08:45:52 -0500

> Does TAP have to be explicitly added to the meson build ?

I tried running my buildfarm using my git repo and my branch, but get the
following error
Status Line: 492 bad branch parameter
Content:
bad branch parameter fix_arm

Web txn failed with status: 1

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 25 Jan 2024 12:30:55 -0500

On 2024-01-24 We 19:02, Michael Paquier wrote:
> [1]:https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Running_on_Windows

I now have an ARM64 machine, so I set up a W11 ARM64 VM. I think we 
really want to build with x64_arm64, i.e. to generate native arm64 
binaries. Setting just x64 will not do that, AIUI.

I tried that with the buidfarm, setting that in the config file's call 
to PGBuild::VSenv::getenv().

That upset msvc_gendef.pl, so I added this there to keep it happy:

    $arch = 'x86_64' if $arch eq 'aarch64';

After that things went ok until I got this:

[1453/2088] "link" @src/backend/postgres.exe.rsp
FAILED: src/backend/postgres.exe src/backend/postgres.pdb
"link" @src/backend/postgres.exe.rsp
    Creating library src\backend\postgres.exe.lib
storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol 
_mm_pause referenced in function perform_spin_delay
src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals

I haven't made further progress, but I will return to it in the next day 
or so.

While this will be nice to have, I think it won't really matter until 
there is ARM64 support in released versions of Windows Server. AFAICT 
they still only sell versions for x86_64

cheers

andrew

---

From: Dave Cramer <[email-masked]>
Date: Thu, 25 Jan 2024 14:07:11 -0500

On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan <[email-masked]> wrote:

> I now have an ARM64 machine, so I set up a W11 ARM64 VM. I think we really
> want to build with x64_arm64, i.e. to generate native arm64 binaries.
> Setting just x64 will not do that, AIUI.
>
> I tried that with the buidfarm, setting that in the config file's call to
> PGBuild::VSenv::getenv().
>
> there is ARM64 support in released versions of Windows Server. AFAICT they
> still only sell versions for x86_64
>

I need it to build clients. The clients need arm64 libraries to link against

Dave

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 25 Jan 2024 14:31:43 -0500

On 2024-01-25 Th 08:45, Dave Cramer wrote:
>
>
>
>
> I tried running my buildfarm using my git repo and my branch, but get 
> the following error

You can't use your own branch with the buildfarm, you need to let it set 
up its own branches.

cheers

andrew

---

From: Dave Cramer <[email-masked]>
Date: Thu, 25 Jan 2024 15:56:20 -0500

> You can't use your own branch with the buildfarm, you need to let it set

So I guess I have to wait until this patch is merged in ?

Dave

---

From: Dave Cramer <[email-masked]>
Date: Thu, 25 Jan 2024 16:01:28 -0500

> still only sell versions for x86_64

I've tried it with my patch attached previously and x64_arm64 and it works
fine. builds using the buildfarm as well.

Is there a definitive way to figure out if the binaries are x64_arm64

Dave

---

From: Anthony Roberts <[email-masked]>
Date: Thu, 25 Jan 2024 21:03:51 +0000

Hi David,

Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.

Thanks,
Anthony

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 25 Jan 2024 16:14:25 -0500

On 2024-01-25 Th 15:56, Dave Cramer wrote:
>>     I tried running my buildfarm using my git repo and my branch, but
>>     get the following error
>     You can't use your own branch with the buildfarm, you need to let
>     it set up its own branches.
>
>

Not quite.

There's a switch that lets you test your own code. If you say 
--from-source /path/to/repo  it will run in whatever state the repo is 
in. It won't care what branch you are on, and it won't try to update the 
repo. It won't report the results to the server, but it will build and 
test everything just like in a regular run. (On the "eat your own dog 
food" principle I use this mode a lot.) If you use that mode you 
probably also want to specify --verbose as well.

cheers

andrew

---

From: Dave Cramer <[email-masked]>
Date: Thu, 25 Jan 2024 16:17:15 -0500

> Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.

So there is another way, select the file in Windows Explorer and right
click, in the compatibility tab if the "Windows on ARM" is greyed out it is
an arm binary.

So far mine are not :(

Thanks,

Dave

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 25 Jan 2024 16:32:39 -0500

On 2024-01-25 Th 16:17, Dave Cramer wrote:
>
>
> On Thu, 25 Jan 2024 at 16:04, Anthony Roberts 
> <[email-masked]> wrote:
>
>     Hi David,
>
> click, in the compatibility tab if the "Windows on ARM" is greyed out 
> it is an arm binary.
>
> So far mine are not :(
>

Yeah, I think the default Developer Command Prompt for VS2022 is set up 
for x86 builds. AIUI you should start by executing "vcvarsall x64_arm64".

cheers

andrew

---

From: Dave Cramer <[email-masked]>
Date: Thu, 25 Jan 2024 16:52:30 -0500

> for x86 builds. AIUI you should start by executing "vcvarsall x64_arm64".

Yup, now I'm in the same state you are

Dave

---

From: Michael Paquier <[email-masked]>
Date: Fri, 26 Jan 2024 10:32:48 +0900

> Yup, now I'm in the same state you are

Wait a minute here.  Based on [1], x64_arm64 means you can use a x64
host and you'll be able to produce ARM64 builds, still these will not
be able to run on the host where they were built.  How much of the
patch posted upthread is required to produce such builds?  Basically 
everything from it, I guess, so as build dependencies can be
satisfied?

[1]: https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
--
Michael

---

From: Andrew Dunstan <[email-masked]>
Date: Fri, 26 Jan 2024 07:36:25 -0500

> [1]: https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170

If you look at the table here x86 and x64 are the only supported host 
architectures. But that's OK, the x64 binaries will run on arm64 (W11 
ARM64 has x64 emulation builtin). If that didn't work Dave and I would 
not have got as far as we have. But you want the x64_arm64 argument to 
vcvarsall so you will get ARM64 output.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

---

From: Dave Cramer <[email-masked]>
Date: Fri, 26 Jan 2024 09:18:50 -0500

On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email-masked]> wrote:

> > [1]:
> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>
>

I've rebuilt it using  x64_arm64 and with the attached (very naive patch)
and I still get an x64 binary :(

---

From: Andrew Dunstan <[email-masked]>
Date: Mon, 29 Jan 2024 10:35:51 -0500

On 2024-01-26 Fr 09:18, Dave Cramer wrote:
> I've rebuilt it using  x64_arm64 and with the attached (very naive 
> patch) and I still get an x64 binary :(

I am definitely getting ARM64 binaries (e.g. for initdb.exe the Windows 
on ARM compatibility setting is greyed out)

I'll try your patch.

cheers

andrew

---

From: Andrew Dunstan <[email-masked]>
Date: Mon, 29 Jan 2024 11:16:41 -0500

> patch) and I still get an x64 binary :(

With this patch I still get a build error, but it's different :-)

[1406/2088] "link" @src/backend/postgres.exe.rsp
FAILED: src/backend/postgres.exe src/backend/postgres.pdb
"link" @src/backend/postgres.exe.rsp
    Creating library src\backend\postgres.exe.lib

storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol 
spin_delay referenced in function perform_spin_delay

cheers

andrew

---

From: Dave Cramer <[email-masked]>
Date: Mon, 29 Jan 2024 11:20:18 -0500

Dave Cramer
www.postgres.rocks

> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals

Did you add the latest lock.patch ?

Dave

---

From: Andrew Dunstan <[email-masked]>
Date: Tue, 30 Jan 2024 08:38:40 -0500

On 2024-01-29 Mo 11:20, Dave Cramer wrote:
>>     I've rebuilt it using  x64_arm64 and with the attached (very
>>     naive patch) and I still get an x64 binary :(
>
>
>     storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external
>     symbol spin_delay referenced in function perform_spin_delay
>

I'm a bit confused about exactly what needs to be applied. Can you 
supply a complete patch to be applied to a pristine checkout that will 
let me build?

cheers

andrew

---

From: Dave Cramer <[email-masked]>
Date: Tue, 30 Jan 2024 09:50:10 -0500

On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan <[email-masked]> wrote:

> I'm a bit confused about exactly what needs to be applied. Can you supply
> a complete patch to be applied to a pristine checkout that will let me
> build?
>
>
> cheers
>

See attached.

Dave

---

From: Andrew Dunstan <[email-masked]>
Date: Tue, 30 Jan 2024 16:56:19 -0500

On 2024-01-30 Tu 09:50, Dave Cramer wrote:
>>     www.postgres.rocks <http://www.postgres.rocks>
>>
>>
>>         storage_lmgr_s_lock.c.obj : error LNK2019: unresolved
>>         external symbol spin_delay referenced in function
>>         perform_spin_delay
>>
>     supply a complete patch to be applied to a pristine checkout that
>     will let me build?
>
>
>     cheers
>
>
> See attached.
>
>

No, that is what is giving me the error shown above (just tried again to 
be certain). And it's not surprising, as patch 2 #ifdef's out the 
definition of spin_delay().

If you can get a complete build with these patches then I suspect you're 
not doing a proper ARM64 build.

cheers

andrew

---

From: Dave Cramer <[email-masked]>
Date: Tue, 30 Jan 2024 17:54:01 -0500

> not doing a proper ARM64 build.
Okay I will look when I get home in a week

Dave

---

From: Andrew Dunstan <[email-masked]>
Date: Wed, 31 Jan 2024 10:20:54 -0500

On 2024-01-30 Tu 17:54, Dave Cramer wrote:
>>>>             I've rebuilt it using x64_arm64 and with the attached
>>>>             (very naive patch) and I still get an x64 binary :(
>>>
>>>
>>         I'm a bit confused about exactly what needs to be applied.
>>         Can you supply a complete patch to be applied to a pristine
>>         checkout that will let me build?
>>
>>
>>         cheers
>>
>>
>>     See attached.
>>
>>
>
>     No, that is what is giving me the error shown above (just tried
>     again to be certain). And it's not surprising, as patch 2 #ifdef's
>     out the definition of spin_delay().
>
>     If you can get a complete build with these patches then I suspect
>     you're not doing a proper ARM64 build.
>
>

I made some progress. The attached is mostly taken from 
<https://postgr.es/m/[email-masked]>

With it applied I was able to get a successful build using the buildfarm 
client. However, there are access violations when running some tests, so 
there is still some work to do, apparently.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index ed5b285a5e..d9b8649dab 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -4150,7 +4150,7 @@ make: *** [postgres] Error 1
    <sect3 id="install-windows-full-64-bit">
     <title>Special Considerations for 64-Bit Windows</title>
     <para>
-     PostgreSQL will only build for the x64 architecture on 64-bit Windows.
+     PostgreSQL will only build for the x64 and ARM64 architecture on 64-bit Windows.
     </para>
     <para>
      Mixing 32- and 64-bit versions in the same build tree is not supported.
diff --git a/meson.build b/meson.build
index 8ed51b6aae..14aea924ec 100644
--- a/meson.build
+++ b/meson.build
@@ -2046,8 +2046,11 @@ int main(void)
 elif host_cpu == 'arm' or host_cpu == 'aarch64'
 
   prog = '''
+#ifdef _MSC_VER
+#include <intrin.h>
+#else
 #include <arm_acle.h>
-
+#endif
 int main(void)
 {
     unsigned int crc = 0;
@@ -2061,7 +2064,11 @@ int main(void)
 }
 '''
 
-  if cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd without -march=armv8-a+crc',
+  if cc.get_id() == 'msvc'
+    cdata.set('USE_ARMV8_CRC32C', false)
+    cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1)
+    have_optimized_crc = true
+  elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd without -march=armv8-a+crc',
       args: test_c_args)
     # Use ARM CRC Extension unconditionally
     cdata.set('USE_ARMV8_CRC32C', 1)
diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
index 69582f4ae7..44abd42691 100644
--- a/src/include/storage/s_lock.h
+++ b/src/include/storage/s_lock.h
@@ -707,15 +707,31 @@ typedef LONG slock_t;
 
 #define SPIN_DELAY() spin_delay()
 
-/* If using Visual C++ on Win64, inline assembly is unavailable.
- * Use a _mm_pause intrinsic instead of rep nop.
+/*
+ * If using Visual C++ on Win64, inline assembly is unavailable.
+ * Use architecture specific intrinsics.
  */
 #if defined(_WIN64)
+/*
+ * For Arm64, use __isb intrinsic. See aarch64 inline assembly definition for details.
+ */
+#ifdef _M_ARM64
+static __forceinline void
+spin_delay(void)
+{
+	 /* Reference: https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics#BarrierRestrictions */
+	__isb(_ARM64_BARRIER_SY);
+}
+#else
+/*
+ * For x64, use _mm_pause intrinsic instead of rep nop.
+ */
 static __forceinline void
 spin_delay(void)
 {
 	_mm_pause();
 }
+#endif
 #else
 static __forceinline void
 spin_delay(void)
diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c
index d47d838c50..f18903a68a 100644
--- a/src/port/pg_crc32c_armv8.c
+++ b/src/port/pg_crc32c_armv8.c
@@ -14,7 +14,9 @@
  */
 #include "c.h"
 
+#ifndef _MSC_VER
 #include <arm_acle.h>
+#endif
 
 #include "port/pg_crc32c.h"
 
diff --git a/src/tools/msvc_gendef.pl b/src/tools/msvc_gendef.pl
index 12c49ed265..dfb26916bd 100644
--- a/src/tools/msvc_gendef.pl
+++ b/src/tools/msvc_gendef.pl
@@ -120,9 +120,9 @@ sub writedef
 	{
 		my $isdata = $def->{$f} eq 'data';
 
-		# Strip the leading underscore for win32, but not x64
+		# Strip the leading underscore for win32, but not x64 and aarch64
 		$f =~ s/^_//
-		  unless ($arch eq "x86_64");
+		  unless ($arch eq "x86_64" || $arch eq "aarch64");
 
 		# Emit just the name if it's a function symbol, or emit the name
 		# decorated with the DATA option for variables.
@@ -143,7 +143,7 @@ sub writedef
 sub usage
 {
 	die("Usage: msvc_gendef.pl --arch <arch> --deffile <deffile> --tempdir <tempdir> files-or-directories\n"
-		  . "    arch: x86 | x86_64\n"
+		  . "    arch: x86 | x86_64 | aarch64\n"
 		  . "    deffile: path of the generated file\n"
 		  . "    tempdir: directory for temporary files\n"
 		  . "    files or directories: object files or directory containing object files\n"
@@ -160,7 +160,7 @@ GetOptions(
 	'tempdir:s' => \$tempdir,) or usage();
 
 usage("arch: $arch")
-  unless ($arch eq 'x86' || $arch eq 'x86_64');
+  unless ($arch eq 'x86' || $arch eq 'x86_64' || $arch eq 'aarch64');
 
 my @files;

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 31 Jan 2024 16:34:13 +0100

> + PostgreSQL will only build for the x64 and ARM64 architecture on 

Are there any other 64-bit architectures for Windows?

Possibly, the original sentence was meant to communicate that ARM was 
not supported, in which case it could now be removed?

---

From: Andrew Dunstan <[email-masked]>
Date: Wed, 31 Jan 2024 10:41:57 -0500

On 2024-01-31 We 10:34, Peter Eisentraut wrote:
>> - PostgreSQL will only build for the x64 architecture on 64-bit 
>> Windows. + PostgreSQL will only build for the x64 and ARM64 
>> architecture on 64-bit Windows.
>

x86? That is in fact the default setting for VS even on ARM64.

cheers

andrew