public inbox for [email protected]help / color / mirror / Atom feed
Re: [PATCH] Add native windows on arm64 support 90+ messages / 11 participants [nested] [flat]
* Re: [PATCH] Add native windows on arm64 support @ 2022-03-23 03:30 Thomas Munro <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Thomas Munro @ 2022-03-23 03:30 UTC (permalink / raw) To: Julien Rouhaud <[email protected]>; +Cc: Niyas Sait <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Mar 22, 2022 at 11:30 PM Julien Rouhaud <[email protected]> wrote: > On Tue, Mar 22, 2022 at 09:37:46AM +0000, Niyas Sait wrote: > > 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.? > > It's all documented at > 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... ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-03-24 01:15 Andres Freund <[email protected]> parent: Thomas Munro <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andres Freund @ 2022-03-24 01:15 UTC (permalink / raw) To: Thomas Munro <[email protected]>; +Cc: Julien Rouhaud <[email protected]>; Niyas Sait <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 2022-03-23 16:30:58 +1300, Thomas Munro wrote: > On Tue, Mar 22, 2022 at 11:30 PM Julien Rouhaud <[email protected]> wrote: > > On Tue, Mar 22, 2022 at 09:37:46AM +0000, Niyas Sait wrote: > > > 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.? > > > > It's all documented at > > 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... 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 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-03-24 22:38 Thomas Munro <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Thomas Munro @ 2022-03-24 22:38 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Julien Rouhaud <[email protected]>; Niyas Sait <[email protected]>; PostgreSQL Hackers <[email protected]> On Thu, Mar 24, 2022 at 2:15 PM Andres Freund <[email protected]> wrote: > 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. 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. ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-04-07 06:36 Michael Paquier <[email protected]> parent: Thomas Munro <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-04-07 06:36 UTC (permalink / raw) To: Thomas Munro <[email protected]>; +Cc: Andres Freund <[email protected]>; Julien Rouhaud <[email protected]>; Niyas Sait <[email protected]>; PostgreSQL Hackers <[email protected]> On Fri, Mar 25, 2022 at 11:38:44AM +1300, Thomas Munro wrote: > 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. 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 Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-04-20 00:28 Michael Paquier <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-04-20 00:28 UTC (permalink / raw) To: Niyas Sait <[email protected]>; +Cc: Andres Freund <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Apr 19, 2022 at 03:22:30PM +0100, Niyas Sait wrote: > Sorry for the delay! Configuring the scripts took some time. I have > successfully run the builfarm animal script using my git repository [1] > which contains the proposed patch on a Windows Arm64 machine. > > I made a request to add a new machine to build farm through [2]. Have you tested with the amount of coverage provided by vcregress.pl? Another thing I was wondering about is if it would be possible to have this option in Travis, but that does not seem to be the case: https://docs.travis-ci.com/user/reference/windows/#windows-version > I believe we should be able to enable the build farm machine once the > change has been merged. Better to wait for the beginning of the development cycle at this stage, based on all the replies received. That would bring us to the beginning of July. + if ($solution->{platform} eq 'ARM64') { + push(@pgportfiles, 'pg_crc32c_armv8_choose.c'); + push(@pgportfiles, 'pg_crc32c_armv8.c'); + } else { + push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); + push(@pgportfiles, 'pg_crc32c_sse42.c'); + } +++ b/src/port/pg_crc32c_armv8.c +#ifndef _MSC_VER #include <arm_acle.h> +#endif [ ... ] +#ifdef _M_ARM64 + /* + * arm64 way of hinting processor for spin loops optimisations + * ref: https://community.arm.com/support-forums/f/infrastructure-solutions-forum/48654/ssetoneon-faq + */ + __isb(_ARM64_BARRIER_SY); +#else I think that such extra optimizations had better be in a separate patch, and we should focus on getting the build done first. + # arm64 linker only supports dynamic base address + my $cfgrandbaseaddress = $self->{platform} eq 'ARM64' ? 'true' : 'false'; This issue is still lying around, and you may have been lucky. Would there be any issues to remove this change to get a basic support in? As mentioned upthread, there is a long history of Postgres with ASLR. This would mean that a basic patch could be done with just the changes for gendef.pl, and the first part of the changes inMSBuildProject.pm. Would that not be enough? -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../Yl9TmT%[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-04-21 04:07 Michael Paquier <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-04-21 04:07 UTC (permalink / raw) To: Niyas Sait <[email protected]>; +Cc: Andres Freund <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Wed, Apr 20, 2022 at 10:43:06AM +0100, Niyas Sait wrote: >> This issue is still lying around, and you may have been lucky. Would >> there be any issues to remove this change to get a basic support in? >> As mentioned upthread, there is a long history of Postgres with ASLR. > > MSVC linker doesn't allow non-random base addresses for Arm64 platforms. > It is needed for basic support. Why does it not allow that? Is that just a limitation of the compiler? If yes, what is the error happening? This question is not exactly answered yet as of this thread. I may be missing a reference about that in the upstream docs, but I see nowhere an explanation about the reason and the why. That's also one of the first questions from Thomas upthread. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-04-25 01:17 Michael Paquier <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-04-25 01:17 UTC (permalink / raw) To: Niyas Sait <[email protected]>; +Cc: Andres Freund <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Thu, Apr 21, 2022 at 10:21:04AM +0100, Niyas Sait wrote: > The following error occurs: > > LINK : fatal error LNK1246: '/DYNAMICBASE:NO' not compatible with 'ARM64' > target machine; link without '/DYNAMICBASE:NO Okay, that's interesting. In light of things like 7f3e17b, that may be annoying. Perhaps newer Windows versions are able to handle that better. I am wondering if it would be worth re-evaluating this change, and attempt to re-enable that in environments other than arm64. This could become interesting if we consider that there have been talks to cut the support for a bunch of Windows versions to focus on the newer ones only. > This seems to be a deliberate restriction for Arm64 targets. However, no > references were provided. To clarify, I have posted a question [1] on the > community channel of Visual Studio. Thanks for doing that! Your post is just a couple of days old, let's see if we get a reply on that. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-05-09 11:44 Niyas Sait <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Niyas Sait @ 2022-05-09 11:44 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> > Thanks for doing that! Your post is just a couple of days old, let's > see if we get a reply on that. Microsoft updated documentation [1] and clarified that ASLR cannot be disabled for Arm64 targets. Because ASLR can't be disabled on ARM, ARM64, or ARM64EC architectures, > /DYNAMICBASE:NO isn't supported for these targets. Thanks Niyas [1] https://docs.microsoft.com/en-us/cpp/build/reference/dynamicbase?view=msvc-170 On Mon, 25 Apr 2022 at 02:17, Michael Paquier <[email protected]> wrote: > On Thu, Apr 21, 2022 at 10:21:04AM +0100, Niyas Sait wrote: > > The following error occurs: > > > > LINK : fatal error LNK1246: '/DYNAMICBASE:NO' not compatible with 'ARM64' > > target machine; link without '/DYNAMICBASE:NO > > Okay, that's interesting. In light of things like 7f3e17b, that may > be annoying. Perhaps newer Windows versions are able to handle that > better. I am wondering if it would be worth re-evaluating this > change, and attempt to re-enable that in environments other than > arm64. This could become interesting if we consider that there have > been talks to cut the support for a bunch of Windows versions to focus > on the newer ones only. > > > This seems to be a deliberate restriction for Arm64 targets. However, no > > references were provided. To clarify, I have posted a question [1] on the > > community channel of Visual Studio. > > Thanks for doing that! Your post is just a couple of days old, let's > see if we get a reply on that. > -- > Michael > ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-05-10 01:01 Michael Paquier <[email protected]> parent: Niyas Sait <[email protected]> 0 siblings, 2 replies; 90+ messages in thread From: Michael Paquier @ 2022-05-10 01:01 UTC (permalink / raw) To: Niyas Sait <[email protected]>; +Cc: Andres Freund <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Mon, May 09, 2022 at 12:44:22PM +0100, Niyas Sait wrote: > Microsoft updated documentation [1] and clarified that ASLR cannot be > disabled for Arm64 targets. > > Because ASLR can't be disabled on ARM, ARM64, or ARM64EC architectures, > > /DYNAMICBASE:NO isn't supported for these targets. Better than nothing, I guess, though this does not stand as a reason explaining why this choice has been made. And it looks like we will never know. We are going to need more advanced testing to check that DYNAMICBASE is stable enough if we begin to enable it. Perhaps we should really look at that for all the build targets we currently support rather than just ARM, for the most modern Win32 environments if we are going to cut support for most of the oldest releases.. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../Ynm5g2152%2FyKc%[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-07-14 08:36 Niyas Sait <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 0 replies; 90+ messages in thread From: Niyas Sait @ 2022-07-14 08:36 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hello, Please find a new patch (no further changes) rebased on top of the master. On Tue, 10 May 2022 at 02:02, Michael Paquier <[email protected]> wrote: > On Mon, May 09, 2022 at 12:44:22PM +0100, Niyas Sait wrote: > > Microsoft updated documentation [1] and clarified that ASLR cannot be > > disabled for Arm64 targets. > > > > Because ASLR can't be disabled on ARM, ARM64, or ARM64EC architectures, > > > /DYNAMICBASE:NO isn't supported for these targets. > > Better than nothing, I guess, though this does not stand as a reason > explaining why this choice has been made. And it looks like we will > never know. We are going to need more advanced testing to check that > DYNAMICBASE is stable enough if we begin to enable it. Perhaps we > should really look at that for all the build targets we currently > support rather than just ARM, for the most modern Win32 environments > if we are going to cut support for most of the oldest releases.. > -- > Michael > -- Niyas Sait Linaro Limited Attachments: [application/octet-stream] v2-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch (5.7K, ../../CAFPTBD_zcrXZihjbyUENiMLkx8JH+FrSEGFr0E0ZX4VKnmoj4w@mail.gmail.com/3-v2-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch) download | inline diff: From 36b5ef714ca4213a25a5f2b02e936826c8dcae43 Mon Sep 17 00:00:00 2001 From: Niyas Sait <[email protected]> Date: Tue, 22 Feb 2022 13:07:24 +0000 Subject: [PATCH v2] Enable postgres native build for windows-arm64 platform Following changes are included - Extend MSVC scripts to handle ARM64 platform - Add arm64 definition of spin_delay function - Exclude arm_acle.h import for MSVC --- src/include/storage/s_lock.h | 10 +++++++++- src/port/pg_crc32c_armv8.c | 2 ++ src/tools/msvc/MSBuildProject.pm | 15 +++++++++++---- src/tools/msvc/Mkvcbuild.pm | 9 +++++++-- src/tools/msvc/Solution.pm | 9 +++++++-- src/tools/msvc/gendef.pl | 8 ++++---- 6 files changed, 40 insertions(+), 13 deletions(-) diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index 1c9f6f0895..5ee3bddabc 100644 --- a/src/include/storage/s_lock.h +++ b/src/include/storage/s_lock.h @@ -703,13 +703,21 @@ 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. + * Use _mm_pause (x64) or __isb(arm64) intrinsic instead of rep nop. */ #if defined(_WIN64) static __forceinline void spin_delay(void) { +#ifdef _M_ARM64 + /* + * arm64 way of hinting processor for spin loops optimisations + * ref: https://community.arm.com/support-forums/f/infrastructure-solutions-forum/48654/ssetoneon-faq + */ + __isb(_ARM64_BARRIER_SY); +#else _mm_pause(); +#endif } #else static __forceinline void diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c index 9e301f96f6..981718752f 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/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm index 62acdda3a1..5128dc9bd6 100644 --- a/src/tools/msvc/MSBuildProject.pm +++ b/src/tools/msvc/MSBuildProject.pm @@ -310,11 +310,18 @@ sub WriteItemDefinitionGroup : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary'); my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ';'); - my $targetmachine = - $self->{platform} eq 'Win32' ? 'MachineX86' : 'MachineX64'; + my $targetmachine; + if ($self->{platform} eq 'Win32') { + $targetmachine = 'MachineX86'; + } elsif ($self->{platform} eq 'ARM64'){ + $targetmachine = 'MachineARM64'; + } else { + $targetmachine = 'MachineX64'; + } my $includes = join ';', @{ $self->{includes} }, ""; - + # arm64 linker only supports dynamic base address + my $cfgrandbaseaddress = $self->{platform} eq 'ARM64' ? 'true' : 'false'; print $f <<EOF; <ItemDefinitionGroup Condition="'\$(Configuration)|\$(Platform)'=='$cfgname|$self->{platform}'"> <ClCompile> @@ -347,7 +354,7 @@ sub WriteItemDefinitionGroup <ProgramDatabaseFile>.\\$cfgname\\$self->{name}\\$self->{name}.pdb</ProgramDatabaseFile> <GenerateMapFile>false</GenerateMapFile> <MapFileName>.\\$cfgname\\$self->{name}\\$self->{name}.map</MapFileName> - <RandomizedBaseAddress>false</RandomizedBaseAddress> + <RandomizedBaseAddress>$cfgrandbaseaddress</RandomizedBaseAddress> <!-- Permit links to MinGW-built, 32-bit DLLs (default before VS2012). --> <ImageHasSafeExceptionHandlers/> <SubSystem>Console</SubSystem> diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index e4feda10fd..fab85a957e 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -114,8 +114,13 @@ sub mkvcbuild if ($vsVersion >= '9.00') { - push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); - push(@pgportfiles, 'pg_crc32c_sse42.c'); + if ($solution->{platform} eq 'ARM64') { + push(@pgportfiles, 'pg_crc32c_armv8_choose.c'); + push(@pgportfiles, 'pg_crc32c_armv8.c'); + } else { + push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); + push(@pgportfiles, 'pg_crc32c_sse42.c'); + } push(@pgportfiles, 'pg_crc32c_sb8.c'); } else diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm index fa32dc371d..6d4ba86167 100644 --- a/src/tools/msvc/Solution.pm +++ b/src/tools/msvc/Solution.pm @@ -67,8 +67,13 @@ sub DeterminePlatform # Examine CL help output to determine if we are in 32 or 64-bit mode. my $output = `cl /help 2>&1`; $? >> 8 == 0 or die "cl command not found"; - $self->{platform} = - ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32'; + if ($output =~ /^\/favor:<.+AMD64/m) { + $self->{platform} = 'x64'; + } elsif($output =~ /for ARM64$/m) { + $self->{platform} = 'ARM64'; + } else { + $self->{platform} = 'Win32'; + } } else { diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl index b8c514a831..2068484b14 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 arm64 $f =~ s/^_// - unless ($platform eq "x64"); + unless ($platform ne "Win32"); # Emit just the name if it's a function symbol, or emit the name # decorated with the DATA option for variables. @@ -144,13 +144,13 @@ sub usage { die( "Usage: gendef.pl <modulepath> <platform>\n" . " modulepath: path to dir with obj files, no trailing slash" - . " platform: Win32 | x64"); + . " platform: Win32 | x64 | ARM64"); } usage() unless scalar(@ARGV) == 2 && ( ($ARGV[0] =~ /\\([^\\]+$)/) - && ($ARGV[1] eq 'Win32' || $ARGV[1] eq 'x64')); + && ($ARGV[1] eq 'Win32' || $ARGV[1] eq 'x64' || $ARGV[1] eq 'ARM64')); my $defname = uc $1; my $deffile = "$ARGV[0]/$defname.def"; my $platform = $ARGV[1]; -- 2.35.0.windows.1 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-26 01:29 Andres Freund <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Andres Freund @ 2022-08-26 01:29 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Niyas Sait <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 2022-05-10 10:01:55 +0900, Michael Paquier wrote: > On Mon, May 09, 2022 at 12:44:22PM +0100, Niyas Sait wrote: > > Microsoft updated documentation [1] and clarified that ASLR cannot be > > disabled for Arm64 targets. > > > > Because ASLR can't be disabled on ARM, ARM64, or ARM64EC architectures, > > > /DYNAMICBASE:NO isn't supported for these targets. > > Better than nothing, I guess, though this does not stand as a reason > explaining why this choice has been made. And it looks like we will > never know. We are going to need more advanced testing to check that > DYNAMICBASE is stable enough if we begin to enable it. Perhaps we > should really look at that for all the build targets we currently > support rather than just ARM, for the most modern Win32 environments > if we are going to cut support for most of the oldest releases.. I accidentally did a lot of testing with DYNAMICBASE - I accidentally mistranslated MSBuildProject.pm's <RandomizedBaseAddress>false</> to adding /DYNAMICBASE in the meson port. Survived several hundred CI cycles and dozens of local runs without observing any problems related to that. Which doesn't surprise me, given the way we reserve space in the new process. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-26 02:09 Michael Paquier <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-08-26 02:09 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Niyas Sait <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Thu, Aug 25, 2022 at 06:29:07PM -0700, Andres Freund wrote: > I accidentally did a lot of testing with DYNAMICBASE - I accidentally > mistranslated MSBuildProject.pm's <RandomizedBaseAddress>false</> to adding > /DYNAMICBASE in the meson port. Survived several hundred CI cycles and dozens > of local runs without observing any problems related to that. > > Which doesn't surprise me, given the way we reserve space in the new process. Still, we had problems with that in the past and I don't recall huge changes in the way we allocate shmem on WIN32. Could there be some stuff in Windows itself that would explain more stability? I would not mind switching back to DYNAMICBASE on HEAD seeing your results. That would simplify this thread's patch a bit as well. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-26 03:29 Andres Freund <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andres Freund @ 2022-08-26 03:29 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Niyas Sait <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 2022-08-26 11:09:41 +0900, Michael Paquier wrote: > On Thu, Aug 25, 2022 at 06:29:07PM -0700, Andres Freund wrote: > > I accidentally did a lot of testing with DYNAMICBASE - I accidentally > > mistranslated MSBuildProject.pm's <RandomizedBaseAddress>false</> to adding > > /DYNAMICBASE in the meson port. Survived several hundred CI cycles and dozens > > of local runs without observing any problems related to that. > > > > Which doesn't surprise me, given the way we reserve space in the new process. > > Still, we had problems with that in the past and I don't recall huge > changes in the way we allocate shmem on WIN32. It's really not great that 7f3e17b4827 disabled randomization without even a comment as to why... There actually seems to have been a lot of work in that area. See 617dc6d299c / bcbf2346d69 and as well as the retrying in 45e004fb4e39. Those weren't prevented by us disabling ASLR. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-27 02:33 Michael Paquier <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 2 replies; 90+ messages in thread From: Michael Paquier @ 2022-08-27 02:33 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Niyas Sait <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Thu, Aug 25, 2022 at 08:29:43PM -0700, Andres Freund wrote: > It's really not great that 7f3e17b4827 disabled randomization without even a > comment as to why... This story is on this thread, with some processes not able to start: https://www.postgresql.org/message-id/BD0D89EC2438455C9DE0DC94D36912F4@maumau > There actually seems to have been a lot of work in that area. See 617dc6d299c > / bcbf2346d69 and as well as the retrying in 45e004fb4e39. Those weren't > prevented by us disabling ASLR. Indeed. 45e004f looks like the most interesting bit here. FWIW, I would not mind re-enabling that on HEAD, as of something like the attached. I have done a dozen of runs without seeing a test failure, and knowing that we don't support anything older than Win10 makes me feel safer about this change. Any objections? -- Michael Attachments: [text/x-diff] 0001-Re-enable-ASLR-on-Windows.patch (973B, ../../YwmCj%[email protected]/2-0001-Re-enable-ASLR-on-Windows.patch) download | inline diff: From 0fde47c2d4e65bd9f1f5a7b4607f8b8b95162242 Mon Sep 17 00:00:00 2001 From: Michael Paquier <[email protected]> Date: Sat, 27 Aug 2022 10:20:53 +0900 Subject: [PATCH] Re-enable ASLR on Windows --- src/tools/msvc/MSBuildProject.pm | 1 - 1 file changed, 1 deletion(-) diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm index 62acdda3a1..594729ceb7 100644 --- a/src/tools/msvc/MSBuildProject.pm +++ b/src/tools/msvc/MSBuildProject.pm @@ -347,7 +347,6 @@ sub WriteItemDefinitionGroup <ProgramDatabaseFile>.\\$cfgname\\$self->{name}\\$self->{name}.pdb</ProgramDatabaseFile> <GenerateMapFile>false</GenerateMapFile> <MapFileName>.\\$cfgname\\$self->{name}\\$self->{name}.map</MapFileName> - <RandomizedBaseAddress>false</RandomizedBaseAddress> <!-- Permit links to MinGW-built, 32-bit DLLs (default before VS2012). --> <ImageHasSafeExceptionHandlers/> <SubSystem>Console</SubSystem> -- 2.37.2 [application/pgp-signature] signature.asc (833B, ../../YwmCj%[email protected]/3-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-27 03:02 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 0 replies; 90+ messages in thread From: Tom Lane @ 2022-08-27 03:02 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Michael Paquier <[email protected]> writes: > Indeed. 45e004f looks like the most interesting bit here. FWIW, I > would not mind re-enabling that on HEAD, as of something like the > attached. I have done a dozen of runs without seeing a test failure, > and knowing that we don't support anything older than Win10 makes me > feel safer about this change. Any objections? We're early enough in the v16 cycle to have plenty of time to detect any problems, so I see little reason not to try it. regards, tom lane ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-27 19:27 Andres Freund <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Andres Freund @ 2022-08-27 19:27 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Niyas Sait <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 2022-08-27 11:33:51 +0900, Michael Paquier wrote: > FWIW, I would not mind re-enabling that on HEAD, as of something like the > attached. I have done a dozen of runs without seeing a test failure, and > knowing that we don't support anything older than Win10 makes me feel safer > about this change. Any objections? +1. We don't have a choice about it on other architectures and it seems like a bad idea to disable on its own. I checked, and it looks like we didn't add --disable-dynamicbase, so ASLR wasn't disabled for mingw builds. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-28 07:23 Michael Paquier <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-08-28 07:23 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Niyas Sait <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Sat, Aug 27, 2022 at 12:27:57PM -0700, Andres Freund wrote: > I checked, and it looks like we didn't add --disable-dynamicbase, so ASLR > wasn't disabled for mingw builds. True enough. I have applied the patch to re-enable that on HEAD. Let's now see what happens in the next couple of days. Popcorn is ready here. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../YwsX3Jf89ucT%[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-28 14:09 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Tom Lane @ 2022-08-28 14:09 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Michael Paquier <[email protected]> writes: > True enough. I have applied the patch to re-enable that on HEAD. > Let's now see what happens in the next couple of days. Popcorn is > ready here. Hmm: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2022-08-28%2010%3A30%3A29 Maybe that's just unrelated noise, but it sure looks weird: after passing the core regression tests in "make check", it failed in pg_upgrade's run with diff -w -U3 H:/prog/bf/root/HEAD/pgsql.build/src/test/regress/expected/xml.out H:/prog/bf/root/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/results/xml.out --- H:/prog/bf/root/HEAD/pgsql.build/src/test/regress/expected/xml.out Wed May 18 18:30:12 2022 +++ H:/prog/bf/root/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/results/xml.out Sun Aug 28 06:55:14 2022 @@ -1557,7 +1557,7 @@ \\x SELECT * FROM XMLTABLE('*' PASSING '<e>pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post</e>' COLUMNS x xml PATH 'node()', y xml PATH '/'); -[ RECORD 1 ]----------------------------------------------------------- -x | pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post +x | pre<?pi arg?><![CDATA[&ent1]]><!--c1--><n2>&deep</n2>post y | <e>pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post</e>+ | I don't recall ever seeing a failure quite like this. regards, tom lane ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-28 15:41 Andres Freund <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andres Freund @ 2022-08-28 15:41 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 2022-08-28 10:09:53 -0400, Tom Lane wrote: > Michael Paquier <[email protected]> writes: > > True enough. I have applied the patch to re-enable that on HEAD. > > Let's now see what happens in the next couple of days. Popcorn is > > ready here. > > Hmm: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2022-08-28%2010%3A30%3A29 > > Maybe that's just unrelated noise, but it sure looks weird: after > passing the core regression tests in "make check", it failed in > pg_upgrade's run with > > diff -w -U3 H:/prog/bf/root/HEAD/pgsql.build/src/test/regress/expected/xml.out H:/prog/bf/root/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/results/xml.out > --- H:/prog/bf/root/HEAD/pgsql.build/src/test/regress/expected/xml.out Wed May 18 18:30:12 2022 > +++ H:/prog/bf/root/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/results/xml.out Sun Aug 28 06:55:14 2022 > @@ -1557,7 +1557,7 @@ > \\x > SELECT * FROM XMLTABLE('*' PASSING '<e>pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post</e>' COLUMNS x xml PATH 'node()', y xml PATH '/'); > -[ RECORD 1 ]----------------------------------------------------------- > -x | pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post > +x | pre<?pi arg?><![CDATA[&ent1]]><!--c1--><n2>&deep</n2>post > y | <e>pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post</e>+ > | Pretty weird, agreed. But hard to see how it could be caused by the randomization change, except that perhaps it could highlight a preexisting bug? Greetings, Andres Freund ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-28 15:51 Tom Lane <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Tom Lane @ 2022-08-28 15:51 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Michael Paquier <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Andres Freund <[email protected]> writes: > On 2022-08-28 10:09:53 -0400, Tom Lane wrote: >> -x | pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post >> +x | pre<?pi arg?><![CDATA[&ent1]]><!--c1--><n2>&deep</n2>post > Pretty weird, agreed. But hard to see how it could be caused by the > randomization change, except that perhaps it could highlight a preexisting > bug? I have no idea either. I agree there *shouldn't* be any connection, so if ASLR is somehow triggering this then whatever is failing is almost certainly buggy on its own terms. But there's a lot of moving parts here (mumble libxml mumble). I'm going to wait to see if it reproduces before spending much effort. regards, tom lane ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-29 01:12 Michael Paquier <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-08-29 01:12 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Sun, Aug 28, 2022 at 11:51:19AM -0400, Tom Lane wrote: > I have no idea either. I agree there *shouldn't* be any connection, > so if ASLR is somehow triggering this then whatever is failing is > almost certainly buggy on its own terms. But there's a lot of > moving parts here (mumble libxml mumble). I'm going to wait to see > if it reproduces before spending much effort. I have noticed that yesterday, but cannot think much about it. This basically changes the position of "<!--c1-->" for the first record, leaving the second one untouched: <!--c1--><?pi arg?><![CDATA[&ent1]]> <?pi arg?><![CDATA[&ent1]]><!--c1--> I am not used to xmltable(), but I wonder if there is something in one of these support functions in xml.c that gets influenced by the randomization. That sounds a bit hairy as make check passed in bowerbird, and I have noticed at least two other Windows hosts running TAP that passed. Or that's just something with libxml itself. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-29 23:48 Michael Paquier <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 2 replies; 90+ messages in thread From: Michael Paquier @ 2022-08-29 23:48 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Mon, Aug 29, 2022 at 10:12:20AM +0900, Michael Paquier wrote: > I have noticed that yesterday, but cannot think much about it. This > basically changes the position of "<!--c1-->" for the first record, > leaving the second one untouched: > <!--c1--><?pi arg?><![CDATA[&ent1]]> > <?pi arg?><![CDATA[&ent1]]><!--c1--> > > I am not used to xmltable(), but I wonder if there is something in one > of these support functions in xml.c that gets influenced by the > randomization. That sounds a bit hairy as make check passed in > bowerbird, and I have noticed at least two other Windows hosts running > TAP that passed. Or that's just something with libxml itself. This is amazing. The issue has showed up a second time in a row in bowerbird, as of: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2022-08-29%2013%3A30%3A32 I don't know what to think about ASLR that manipulates the comment in this XML object under VS 2017 (perhaps a compiler issue?), but it should be possible to go back to green simply by removing "<!--c1-->" from the input string. Creating an extra output pattern here would be very costly, as xml_2.out and xml.out have outputs for --with-libxml. Would people object if I do that for now? -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-29 23:58 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Tom Lane @ 2022-08-29 23:58 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Michael Paquier <[email protected]> writes: > This is amazing. The issue has showed up a second time in a row in > bowerbird, as of: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2022-08-29%2013%3A30%3A32 That is fascinating. > I don't know what to think about ASLR that manipulates the comment in > this XML object under VS 2017 (perhaps a compiler issue?), but it > should be possible to go back to green simply by removing "<!--c1-->" > from the input string. Creating an extra output pattern here would be > very costly, as xml_2.out and xml.out have outputs for --with-libxml. > Would people object if I do that for now? Let's let it go for a few more runs. I want to know whether it reproduces 100% or only sometimes. regards, tom lane ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-30 00:09 Andres Freund <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 0 replies; 90+ messages in thread From: Andres Freund @ 2022-08-30 00:09 UTC (permalink / raw) To: Michael Paquier <[email protected]>; Andrew Dunstan <[email protected]>; +Cc: Tom Lane <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 2022-08-30 08:48:38 +0900, Michael Paquier wrote: > On Mon, Aug 29, 2022 at 10:12:20AM +0900, Michael Paquier wrote: > > I have noticed that yesterday, but cannot think much about it. This > > basically changes the position of "<!--c1-->" for the first record, > > leaving the second one untouched: > > <!--c1--><?pi arg?><![CDATA[&ent1]]> > > <?pi arg?><![CDATA[&ent1]]><!--c1--> > > > > I am not used to xmltable(), but I wonder if there is something in one > > of these support functions in xml.c that gets influenced by the > > randomization. That sounds a bit hairy as make check passed in > > bowerbird, and I have noticed at least two other Windows hosts running > > TAP that passed. Or that's just something with libxml itself. > > This is amazing. The issue has showed up a second time in a row in > bowerbird, as of: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2022-08-29%2013%3A30%3A32 > > I don't know what to think about ASLR that manipulates the comment in > this XML object under VS 2017 (perhaps a compiler issue?), but it > should be possible to go back to green simply by removing "<!--c1-->" > from the input string. Creating an extra output pattern here would be > very costly, as xml_2.out and xml.out have outputs for --with-libxml. > > Would people object if I do that for now? I do. Clearly something is wrong, what do we gain by averting our eyes? An alternative output file strikes me as an equally bad idea - it's not like this is a case where there are legitimately different outputs? Bowerbird is the only animal testing libxml with visual studio afaics. And CI doesn't have libxml either. So we have no idea if it's the msvc version that matters. Andrew, what version of libxml is installed? Afaict we don't see that anywhere with msvc. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-30 00:33 Andres Freund <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andres Freund @ 2022-08-30 00:33 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 2022-08-29 19:58:31 -0400, Tom Lane wrote: > Michael Paquier <[email protected]> writes: > > This is amazing. The issue has showed up a second time in a row in > > bowerbird, as of: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2022-08-29%2013%3A30%3A32 > > That is fascinating. > > I don't know what to think about ASLR that manipulates the comment in > > this XML object under VS 2017 (perhaps a compiler issue?), but it > > should be possible to go back to green simply by removing "<!--c1-->" > > from the input string. Creating an extra output pattern here would be > > very costly, as xml_2.out and xml.out have outputs for --with-libxml. > > > Would people object if I do that for now? > > Let's let it go for a few more runs. I want to know whether it > reproduces 100% or only sometimes. The weirdest part is that it only happens as part of the the pg_upgrade test. I just tested it in my test windows vm (win 10, vs 2019), with a build of libxml I had around (2.9.7), and the regression tests passed both "normally" and within pg_upgrade. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-30 01:35 Michael Paquier <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-08-30 01:35 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Tom Lane <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Mon, Aug 29, 2022 at 05:33:56PM -0700, Andres Freund wrote: > The weirdest part is that it only happens as part of the the pg_upgrade test. make check has just failed: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2022-08-30%2001%3A15%3A13 > I just tested it in my test windows vm (win 10, vs 2019), with a build of > libxml I had around (2.9.7), and the regression tests passed both "normally" > and within pg_upgrade. bowerbird is feeling from c:\\prog\\3p64\\include\\libxml2 and c:\\prog\\3p64\\lib\\libxml2.lib. I am not sure which version of libxml this is, and the other animals of MSVC don't use libxml so it is not possible to correlate that only to VS 2017, either. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../Yw1pZ8X3rG%[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-30 02:00 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Tom Lane @ 2022-08-30 02:00 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Michael Paquier <[email protected]> writes: > On Mon, Aug 29, 2022 at 05:33:56PM -0700, Andres Freund wrote: >> The weirdest part is that it only happens as part of the the pg_upgrade test. > make check has just failed: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2022-08-30%2001%3A15%3A13 So it *is* probabilistic, which is pretty much what you'd expect if ASLR triggers it. That brings us no closer to understanding what the mechanism is, though. regards, tom lane ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-30 23:36 Michael Paquier <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 2 replies; 90+ messages in thread From: Michael Paquier @ 2022-08-30 23:36 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Mon, Aug 29, 2022 at 10:00:10PM -0400, Tom Lane wrote: > Michael Paquier <[email protected]> writes: > > On Mon, Aug 29, 2022 at 05:33:56PM -0700, Andres Freund wrote: > >> The weirdest part is that it only happens as part of the the pg_upgrade test. > > > make check has just failed: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2022-08-30%2001%3A15%3A13 > > So it *is* probabilistic, which is pretty much what you'd expect > if ASLR triggers it. That brings us no closer to understanding > what the mechanism is, though. There have been more failures, always switching the input from "pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post" to "pre<?pi arg?><![CDATA[&ent1]]><!--c1--><n2>&deep</n2>post". Using a PATH of node() influences the output. I am not verse unto XMLTABLE, but could it be an issue where each node is parsed and we have something like a qsort() applied on the pointer addresses for each part or something like that, causing the output to become unstable? -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-31 00:07 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Tom Lane @ 2022-08-31 00:07 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Michael Paquier <[email protected]> writes: > Using a PATH of node() influences the output. I am not verse unto > XMLTABLE, but could it be an issue where each node is parsed and we > have something like a qsort() applied on the pointer addresses for > each part or something like that, causing the output to become > unstable? I'm not sure. I dug into this enough to find that the output from this query is generated in xml.c lines 4635ff: /* Concatenate serialized values */ initStringInfo(&str); for (int i = 0; i < count; i++) { textstr = xml_xmlnodetoxmltype(xpathobj->nodesetval->nodeTab[i], xtCxt->xmlerrcxt); appendStringInfoText(&str, textstr); } cstr = str.data; So evidently, the problem occurs because the elements of the nodesetval->nodeTab[] array are in a different order than we expect. I looked into <xpath.h> and found the definition of the "nodesetval" struct, and the comments are eye-opening to say the least: /* * A node-set (an unordered collection of nodes without duplicates). */ typedef struct _xmlNodeSet xmlNodeSet; typedef xmlNodeSet *xmlNodeSetPtr; struct _xmlNodeSet { int nodeNr; /* number of nodes in the set */ int nodeMax; /* size of the array as allocated */ xmlNodePtr *nodeTab; /* array of nodes in no particular order */ /* @@ with_ns to check wether namespace nodes should be looked at @@ */ }; It seems like maybe we're relying on an ordering we should not. Yet surely the ordering of the pieces of this output is meaningful? Are we using the wrong libxml API to create this result? Anyway, I'm now suspicious that we've accidentally exposed a logic bug in the XMLTABLE code, rather than anything wrong with the ASLR stuff. regards, tom lane ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-31 00:15 Michael Paquier <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-08-31 00:15 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Wed, Aug 31, 2022 at 08:36:01AM +0900, Michael Paquier wrote: > There have been more failures, always switching the input from > "pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post" > to "pre<?pi arg?><![CDATA[&ent1]]><!--c1--><n2>&deep</n2>post". > > Using a PATH of node() influences the output. I am not verse unto > XMLTABLE, but could it be an issue where each node is parsed and we > have something like a qsort() applied on the pointer addresses for > each part or something like that, causing the output to become > unstable? Hmm. I think that I may have an idea here after looking at our xml.c and xpath.c in libxml2/. From what I understand, we process the PATH through XmlTableGetValue() that builds a XML node path in xmlXPathCompiledEval(). The interesting part comes from libxml2's xmlXPathCompiledEvalInternal(), where I think we don't apply a sort on the contents generated. Hence, I am wondering if the solution here would be to do one xmlXPathNodeSetSort(xpathobj->nodesetval) after compiling the path with xmlXPathCompiledEval() in XmlTableGetValue(). This should ensure that the items are ordered even if ASLR mixes if the pointer positions. A complete solution would involve more code paths, but we'd need only one change in XmlTableGetValue() for the current regression tests to work. I don't have an environment where I can reproduce that, so that would be up to the buildfarm to stress this solution.. Thoughts? -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-31 00:16 Michael Paquier <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 90+ messages in thread From: Michael Paquier @ 2022-08-31 00:16 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Aug 30, 2022 at 08:07:27PM -0400, Tom Lane wrote: > It seems like maybe we're relying on an ordering we should not. > Yet surely the ordering of the pieces of this output is meaningful? > Are we using the wrong libxml API to create this result? > > Anyway, I'm now suspicious that we've accidentally exposed a logic > bug in the XMLTABLE code, rather than anything wrong with the > ASLR stuff. Funny. I have reached basically the same conclusion as you a couple of minutes ago, but I also think that I have found what we need to do here to ensure the ordering of the nodes generated by the libxml code. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-31 00:28 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Tom Lane @ 2022-08-31 00:28 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Michael Paquier <[email protected]> writes: > Hence, I am wondering if the solution here > would be to do one xmlXPathNodeSetSort(xpathobj->nodesetval) after > compiling the path with xmlXPathCompiledEval() in XmlTableGetValue(). Hmm, I see that function declared in <xpathInternals.h>, which sure doesn't give me a warm feeling that we're supposed to call it directly. But maybe there's an approved way to get the result. Or perhaps this test case is wrong, and instead of "node()" we need to write something that specifies a sorted result? regards, tom lane ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-31 06:09 Michael Paquier <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-08-31 06:09 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Aug 30, 2022 at 08:28:58PM -0400, Tom Lane wrote: > Hmm, I see that function declared in <xpathInternals.h>, which > sure doesn't give me a warm feeling that we're supposed to call it > directly. But maybe there's an approved way to get the result. > > Or perhaps this test case is wrong, and instead of "node()" we > need to write something that specifies a sorted result? I am no specialist on this matter.. Still, looking around, this looks to be the kind of job that xsl:sort would do? We cannot use it here for an XML-only context, though, and it does not seem like there is a direct way to enforce the ordering per the nature of the XPath language, either. I may be missing something of course. Please note that I am also getting a bit the cold feet with the idea of enforcing a sorting of the elements in the generated output, actually, as this could have a performance penalty for all users particularly on large blobs of data. At the end, I'd like to think that it would be wiser to just remove entirely the test for node() or reduce the contents of the string to be able to strictly control the output order (say a simple '<e>pre<![CDATA[&ent1]]>post</e>' would do the trick). I cannot think about a better idea now. Note that removing the test case where we have node() has no impact on the coverage of xml.c. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-08-31 17:33 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Tom Lane @ 2022-08-31 17:33 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Michael Paquier <[email protected]> writes: > At the end, I'd like to think that it would be wiser to just remove > entirely the test for node() or reduce the contents of the string to > be able to strictly control the output order (say a simple > '<e>pre<![CDATA[&ent1]]>post</e>' would do the trick). I cannot think > about a better idea now. Note that removing the test case where we > have node() has no impact on the coverage of xml.c. Yeah, I confirm that: local code-coverage testing shows no change in the number of lines reached in xml.c when I remove that column: -SELECT * FROM XMLTABLE('*' PASSING '<e>pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post</e>' COLUMNS x xml PATH 'node()', y xml PATH '/'); +SELECT * FROM XMLTABLE('*' PASSING '<e>pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post</e>' COLUMNS y xml PATH '/'); Dropping the query altogether does result in a reduction in the number of lines hit. I did not check the other XMLTABLE infrastructure, so what probably is best to do is keep the two output columns but change 'node()' to something with a more stable result; any preferences? regards, tom lane ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-09-01 00:32 Michael Paquier <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-09-01 00:32 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Wed, Aug 31, 2022 at 01:33:53PM -0400, Tom Lane wrote: > I did not check the other XMLTABLE infrastructure, so what probably > is best to do is keep the two output columns but change 'node()' > to something with a more stable result; any preferences? The input object could also be reworked so as we would not have any ordering issues, say "<e>pre<f><g><n2>&deep</n2></g></f>post</e>". Changing only the path, you could use "/e/n2" instead of "node()", so as we'd always get the most internal member. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../Yw%2F9pgS35urJZu%[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-09-01 02:22 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Tom Lane @ 2022-09-01 02:22 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Michael Paquier <[email protected]> writes: > The input object could also be reworked so as we would not have any > ordering issues, say "<e>pre<f><g><n2>&deep</n2></g></f>post</e>". > Changing only the path, you could use "/e/n2" instead of "node()", so > as we'd always get the most internal member. Done that way. regards, tom lane ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-09-01 04:41 Michael Paquier <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-09-01 04:41 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Wed, Aug 31, 2022 at 10:22:06PM -0400, Tom Lane wrote: > Michael Paquier <[email protected]> writes: > > The input object could also be reworked so as we would not have any > > ordering issues, say "<e>pre<f><g><n2>&deep</n2></g></f>post</e>". > > Changing only the path, you could use "/e/n2" instead of "node()", so > > as we'd always get the most internal member. > > Done that way. Cool, thanks. bowerbird looks happy after its first run. An argument in favor of backpatching is if one decides to build the code with MSVC and patch the scripts to enable ASLR. However, nobody has complained about that yet, so fine by me to leave this change only on HEAD for now. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-11-03 08:38 Ian Lawrence Barwick <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Ian Lawrence Barwick @ 2022-11-03 08:38 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> 2022年9月1日(木) 13:42 Michael Paquier <[email protected]>: > > On Wed, Aug 31, 2022 at 10:22:06PM -0400, Tom Lane wrote: > > Michael Paquier <[email protected]> writes: > > > The input object could also be reworked so as we would not have any > > > ordering issues, say "<e>pre<f><g><n2>&deep</n2></g></f>post</e>". > > > Changing only the path, you could use "/e/n2" instead of "node()", so > > > as we'd always get the most internal member. > > > > Done that way. > > Cool, thanks. bowerbird looks happy after its first run. > > An argument in favor of backpatching is if one decides to build the > code with MSVC and patch the scripts to enable ASLR. However, nobody > has complained about that yet, so fine by me to leave this change only > on HEAD for now. Apologies for the thread bump, but there is an entry for this thread in the current CF previously marked "Needs review": https://commitfest.postgresql.org/40/3561/ I've gone ahead and marked it as "Committed", as that appears to have happened back in August as 36389a060c. If for whatever reason that was the Wrong Thing To Do, please let me know. Regards Ian Barwick ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-11-03 11:06 Niyas Sait <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 0 siblings, 2 replies; 90+ messages in thread From: Niyas Sait @ 2022-11-03 11:06 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; +Cc: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> > I've gone ahead and marked it as "Committed", as that appears to have happened > back in August as 36389a060c. > If for whatever reason that was the Wrong Thing To Do, please let me know. 36389a060c commit enables ASLR for windows but does not include other changes required for Arm64. I've attached a new version of the patch which excludes the already merged ASLR changes and add small changes to handle latest changes in the build scripts. On Thu, 3 Nov 2022 at 08:38, Ian Lawrence Barwick <[email protected]> wrote: > 2022年9月1日(木) 13:42 Michael Paquier <[email protected]>: > > > > On Wed, Aug 31, 2022 at 10:22:06PM -0400, Tom Lane wrote: > > > Michael Paquier <[email protected]> writes: > > > > The input object could also be reworked so as we would not have any > > > > ordering issues, say > "<e>pre<f><g><n2>&deep</n2></g></f>post</e>". > > > > Changing only the path, you could use "/e/n2" instead of "node()", so > > > > as we'd always get the most internal member. > > > > > > Done that way. > > > > Cool, thanks. bowerbird looks happy after its first run. > > > > An argument in favor of backpatching is if one decides to build the > > code with MSVC and patch the scripts to enable ASLR. However, nobody > > has complained about that yet, so fine by me to leave this change only > > on HEAD for now. > > Apologies for the thread bump, but there is an entry for this thread > in the current CF > previously marked "Needs review": > > https://commitfest.postgresql.org/40/3561/ > > I've gone ahead and marked it as "Committed", as that appears to have > happened > back in August as 36389a060c. > > If for whatever reason that was the Wrong Thing To Do, please let me know. > > Regards > > Ian Barwick > -- Niyas Sait Linaro Limited Attachments: [application/octet-stream] v3-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch (5.1K, ../../CAFPTBD8CCT9BNdQQ0QELoo7HPqx26_Zkn0jxg9F9u+bPz-jnEg@mail.gmail.com/3-v3-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch) download | inline diff: From db7b0def74f4cbd525fd77b96971c523cdf82035 Mon Sep 17 00:00:00 2001 From: Niyas Sait <[email protected]> Date: Tue, 22 Feb 2022 13:07:24 +0000 Subject: [PATCH v3] Enable postgres native build for windows-arm64 platform Following changes are included - Extend MSVC scripts to handle ARM64 platform - Add arm64 definition of spin_delay function - Exclude arm_acle.h import for MSVC --- src/include/storage/s_lock.h | 10 +++++++++- src/port/pg_crc32c_armv8.c | 2 ++ src/tools/msvc/MSBuildProject.pm | 16 ++++++++++++---- src/tools/msvc/Mkvcbuild.pm | 9 +++++++-- src/tools/msvc/Solution.pm | 9 +++++++-- src/tools/msvc/gendef.pl | 8 ++++---- 6 files changed, 41 insertions(+), 13 deletions(-) diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index 8b19ab160f..bf6a6dba35 100644 --- a/src/include/storage/s_lock.h +++ b/src/include/storage/s_lock.h @@ -708,13 +708,21 @@ 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. + * Use _mm_pause (x64) or __isb(arm64) intrinsic instead of rep nop. */ #if defined(_WIN64) static __forceinline void spin_delay(void) { +#ifdef _M_ARM64 + /* + * arm64 way of hinting processor for spin loops optimisations + * ref: https://community.arm.com/support-forums/f/infrastructure-solutions-forum/48654/ssetoneon-faq + */ + __isb(_ARM64_BARRIER_SY); +#else _mm_pause(); +#endif } #else static __forceinline void diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c index 9e301f96f6..981718752f 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/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm index 58590fdac2..caf390d982 100644 --- a/src/tools/msvc/MSBuildProject.pm +++ b/src/tools/msvc/MSBuildProject.pm @@ -310,10 +310,18 @@ sub WriteItemDefinitionGroup : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary'); my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ';'); - my $targetmachine = - $self->{platform} eq 'Win32' ? 'MachineX86' : 'MachineX64'; - my $arch = - $self->{platform} eq 'Win32' ? 'x86' : 'x86_64'; + my $targetmachine; + my $arch; + if ($self->{platform} eq 'Win32') { + $targetmachine = 'MachineX86'; + $arch = 'x86'; + } elsif ($self->{platform} eq 'ARM64'){ + $targetmachine = 'MachineARM64'; + $arch = 'arm64'; + } else { + $targetmachine = 'MachineX64'; + $arch = 'x86_64'; + } my $includes = join ';', @{ $self->{includes} }, ""; diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index 83a3e40425..71baed26e9 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -123,8 +123,13 @@ sub mkvcbuild if ($vsVersion >= '9.00') { - push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); - push(@pgportfiles, 'pg_crc32c_sse42.c'); + if ($solution->{platform} eq 'ARM64') { + push(@pgportfiles, 'pg_crc32c_armv8_choose.c'); + push(@pgportfiles, 'pg_crc32c_armv8.c'); + } else { + push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); + push(@pgportfiles, 'pg_crc32c_sse42.c'); + } push(@pgportfiles, 'pg_crc32c_sb8.c'); } else diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm index c2acb58df0..e3fa0f968e 100644 --- a/src/tools/msvc/Solution.pm +++ b/src/tools/msvc/Solution.pm @@ -67,8 +67,13 @@ sub DeterminePlatform # Examine CL help output to determine if we are in 32 or 64-bit mode. my $output = `cl /help 2>&1`; $? >> 8 == 0 or die "cl command not found"; - $self->{platform} = - ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32'; + if ($output =~ /^\/favor:<.+AMD64/m) { + $self->{platform} = 'x64'; + } elsif($output =~ /for ARM64$/m) { + $self->{platform} = 'ARM64'; + } else { + $self->{platform} = 'Win32'; + } } else { diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl index d6bed1ce15..f1e0ff446b 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 arm64 $f =~ s/^_// - unless ($arch eq "x86_64"); + unless ($arch ne "x86"); # 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: gendef.pl --arch <arch> --deffile <deffile> --tempdir <tempdir> files-or-directories\n" - . " arch: x86 | x86_64\n" + . " arch: x86 | x86_64 | arm64 \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 'arm64'); my @files; -- 2.38.1 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-11-03 11:43 Michael Paquier <[email protected]> parent: Niyas Sait <[email protected]> 1 sibling, 0 replies; 90+ messages in thread From: Michael Paquier @ 2022-11-03 11:43 UTC (permalink / raw) To: Niyas Sait <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Thu, Nov 03, 2022 at 11:06:46AM +0000, Niyas Sait wrote: > > I've gone ahead and marked it as "Committed", as that appears to have > happened > > back in August as 36389a060c. > > If for whatever reason that was the Wrong Thing To Do, please let me know. > > 36389a060c commit enables ASLR for windows but does not include other > changes required for Arm64. Yes, marking this patch as committed is incorrect. That's just me lagging behind for the review :) I have switched that back as "Needs review" for the moment. > I've attached a new version of the patch which excludes the already merged > ASLR changes and add > small changes to handle latest changes in the build scripts. Thanks. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-11-05 18:31 Andres Freund <[email protected]> parent: Niyas Sait <[email protected]> 1 sibling, 2 replies; 90+ messages in thread From: Andres Freund @ 2022-11-05 18:31 UTC (permalink / raw) To: Niyas Sait <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 2022-11-03 11:06:46 +0000, Niyas Sait wrote: > I've attached a new version of the patch which excludes the already merged > ASLR changes and add > small changes to handle latest changes in the build scripts. Note that we're planning to remove the custom windows build scripts before the next release, relying on the meson build instead. > diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h > index 8b19ab160f..bf6a6dba35 100644 > --- a/src/include/storage/s_lock.h > +++ b/src/include/storage/s_lock.h > @@ -708,13 +708,21 @@ 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. > + * Use _mm_pause (x64) or __isb(arm64) intrinsic instead of rep nop. > */ > #if defined(_WIN64) > static __forceinline void > spin_delay(void) > { > +#ifdef _M_ARM64 > + /* > + * arm64 way of hinting processor for spin loops optimisations > + * ref: https://community.arm.com/support-forums/f/infrastructure-solutions-forum/48654/ssetoneon-faq > + */ > + __isb(_ARM64_BARRIER_SY); > +#else > _mm_pause(); > +#endif > } > #else > static __forceinline void I think we should just apply this, there seems very little risk of making anything worse, given the gating to _WIN64 && _M_ARM64. > diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c > index 9e301f96f6..981718752f 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" This won't suffice with the meson build, since the relevant configure test also uses arm_acle.h: elif host_cpu == 'arm' or host_cpu == 'aarch64' prog = ''' #include <arm_acle.h> int main(void) { unsigned int crc = 0; crc = __crc32cb(crc, 0); crc = __crc32ch(crc, 0); crc = __crc32cw(crc, 0); crc = __crc32cd(crc, 0); /* return computed value, to prevent the above being optimized away */ return crc == 0; } ''' if 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) have_optimized_crc = true elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', args: test_c_args + ['-march=armv8-a+crc']) # Use ARM CRC Extension, with runtime check cflags_crc += '-march=armv8-a+crc' cdata.set('USE_ARMV8_CRC32C', false) cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) have_optimized_crc = true endif endif The meson checking logic is used both for msvc and other compilers, so this will need to work with both. > diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl > index d6bed1ce15..f1e0ff446b 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 arm64 > $f =~ s/^_// > - unless ($arch eq "x86_64"); > + unless ($arch ne "x86"); > > # 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: gendef.pl --arch <arch> --deffile <deffile> --tempdir <tempdir> files-or-directories\n" > - . " arch: x86 | x86_64\n" > + . " arch: x86 | x86_64 | arm64 \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 'arm64'); > > my @files; > Seems reasonable. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-11-07 06:58 Michael Paquier <[email protected]> parent: Andres Freund <[email protected]> 1 sibling, 2 replies; 90+ messages in thread From: Michael Paquier @ 2022-11-07 06:58 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Sat, Nov 05, 2022 at 11:31:36AM -0700, Andres Freund wrote: > On 2022-11-03 11:06:46 +0000, Niyas Sait wrote: > Note that we're planning to remove the custom windows build scripts before the > next release, relying on the meson build instead. Youpi. >> #if defined(_WIN64) >> static __forceinline void >> spin_delay(void) >> { >> +#ifdef _M_ARM64 >> + /* >> + * arm64 way of hinting processor for spin loops optimisations >> + * ref: https://community.arm.com/support-forums/f/infrastructure-solutions-forum/48654/ssetoneon-faq >> + */ >> + __isb(_ARM64_BARRIER_SY); >> +#else >> _mm_pause(); >> +#endif >> } >> #else >> static __forceinline void > > I think we should just apply this, there seems very little risk of making > anything worse, given the gating to _WIN64 && _M_ARM64. Seems so. Hmm, where does _ARM64_BARRIER_SY come from? Perhaps it would be better to have a comment referring to it from a different place than the forums of arm, like some actual docs? > The meson checking logic is used both for msvc and other compilers, so this > will need to work with both. The patch has been switched as waiting on author for now. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-01 07:42 Michael Paquier <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 0 replies; 90+ messages in thread From: Michael Paquier @ 2022-12-01 07:42 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Mon, Nov 07, 2022 at 03:58:13PM +0900, Michael Paquier wrote: > The patch has been switched as waiting on author for now. Seeing no replies after three weeks, I have marked the patch as returned with feedback for now. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-01 17:17 Niyas Sait <[email protected]> parent: Andres Freund <[email protected]> 1 sibling, 0 replies; 90+ messages in thread From: Niyas Sait @ 2022-12-01 17:17 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On 05/11/2022 18:31, Andres Freund wrote: > On 2022-11-03 11:06:46 +0000, Niyas Sait wrote: >> I've attached a new version of the patch which excludes the already merged >> ASLR changes and add >> small changes to handle latest changes in the build scripts. > Note that we're planning to remove the custom windows build scripts before the > next release, relying on the meson build instead. > Thanks. I will add changes to add meson build support. > This won't suffice with the meson build, since the relevant configure test > also uses arm_acle.h: > elif host_cpu == 'arm' or host_cpu == 'aarch64' > > prog = ''' > #include <arm_acle.h> > > int main(void) > { > unsigned int crc = 0; > crc = __crc32cb(crc, 0); > crc = __crc32ch(crc, 0); > crc = __crc32cw(crc, 0); > crc = __crc32cd(crc, 0); > > /* return computed value, to prevent the above being optimized away */ > return crc == 0; > } > ''' > > if 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) > have_optimized_crc = true > elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', > args: test_c_args + ['-march=armv8-a+crc']) > # Use ARM CRC Extension, with runtime check > cflags_crc += '-march=armv8-a+crc' > cdata.set('USE_ARMV8_CRC32C', false) > cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) > have_optimized_crc = true > endif > endif > > The meson checking logic is used both for msvc and other compilers, so this > will need to work with both. Yes, will handle that. -- Niyas ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-01 17:20 Niyas Sait <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 2 replies; 90+ messages in thread From: Niyas Sait @ 2022-12-01 17:20 UTC (permalink / raw) To: Michael Paquier <[email protected]>; Andres Freund <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On 07/11/2022 06:58, Michael Paquier wrote: >>> #if defined(_WIN64) >>> static __forceinline void >>> spin_delay(void) >>> { >>> +#ifdef _M_ARM64 >>> + /* >>> + * arm64 way of hinting processor for spin loops optimisations >>> + * ref: https://community.arm.com/support-forums/f/infrastructure-solutions-forum/48654/ssetoneon-faq >>> + */ >>> + __isb(_ARM64_BARRIER_SY); >>> +#else >>> _mm_pause(); >>> +#endif >>> } >>> #else >>> static __forceinline void >> >> I think we should just apply this, there seems very little risk of making >> anything worse, given the gating to _WIN64 && _M_ARM64. > > Seems so. Hmm, where does _ARM64_BARRIER_SY come from? Perhaps it > would be better to have a comment referring to it from a different > place than the forums of arm, like some actual docs? _ARM64_BARRIER_SY is defined in Microsoft Arm64 intrinsic documentation - https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics?view=msvc-170#BarrierRestrictions I couldn't find something more official for the sse2neon library part. -- Niyas ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-01 17:53 Niyas Sait <[email protected]> parent: Niyas Sait <[email protected]> 1 sibling, 2 replies; 90+ messages in thread From: Niyas Sait @ 2022-12-01 17:53 UTC (permalink / raw) To: Michael Paquier <[email protected]>; Andres Freund <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hello, I've attached a new revision of the patch (v4) and includes following changes, 1. Add support for meson build system 2. Extend MSVC scripts to handle ARM64 platform. 3. Add arm64 definition of spin_delay function. 4. Exclude arm_acle.h import with MSVC compiler. V3->V4: Add support for meson build system V2->V3: Removed ASLR enablement and rebased on master. V1->V2: Rebased on top of master -- Niyas From 872f538f6261b36a32cbcecae82e99778b747799 Mon Sep 17 00:00:00 2001 From: Niyas Sait <[email protected]> Date: Tue, 22 Feb 2022 13:07:24 +0000 Subject: [PATCH v4] Enable postgres native build for windows-arm64 platform Following changes are included - Extend MSVC scripts to handle ARM64 platform - Add arm64 definition of spin_delay function - Exclude arm_acle.h import for MSVC - Add support for meson build --- meson.build | 33 +++++++++++++++++++------------- src/include/storage/s_lock.h | 10 +++++++++- src/port/pg_crc32c_armv8.c | 2 ++ src/tools/msvc/MSBuildProject.pm | 16 ++++++++++++---- src/tools/msvc/Mkvcbuild.pm | 9 +++++++-- src/tools/msvc/Solution.pm | 11 ++++++++--- src/tools/msvc/gendef.pl | 8 ++++---- 7 files changed, 62 insertions(+), 27 deletions(-) diff --git a/meson.build b/meson.build index 725e10d815..e354ad7650 100644 --- a/meson.build +++ b/meson.build @@ -1944,7 +1944,13 @@ int main(void) elif host_cpu == 'arm' or host_cpu == 'aarch64' - prog = ''' + if cc.get_id() == 'msvc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + else + + prog = ''' #include <arm_acle.h> int main(void) @@ -1960,18 +1966,19 @@ int main(void) } ''' - if 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) - have_optimized_crc = true - elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', - args: test_c_args + ['-march=armv8-a+crc']) - # Use ARM CRC Extension, with runtime check - cflags_crc += '-march=armv8-a+crc' - cdata.set('USE_ARMV8_CRC32C', false) - cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) - have_optimized_crc = true + if 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) + have_optimized_crc = true + elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', + args: test_c_args + ['-march=armv8-a+crc']) + # Use ARM CRC Extension, with runtime check + cflags_crc += '-march=armv8-a+crc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + endif endif endif diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index 8b19ab160f..bf6a6dba35 100644 --- a/src/include/storage/s_lock.h +++ b/src/include/storage/s_lock.h @@ -708,13 +708,21 @@ 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. + * Use _mm_pause (x64) or __isb(arm64) intrinsic instead of rep nop. */ #if defined(_WIN64) static __forceinline void spin_delay(void) { +#ifdef _M_ARM64 + /* + * arm64 way of hinting processor for spin loops optimisations + * ref: https://community.arm.com/support-forums/f/infrastructure-solutions-forum/48654/ssetoneon-faq + */ + __isb(_ARM64_BARRIER_SY); +#else _mm_pause(); +#endif } #else static __forceinline void diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c index 9e301f96f6..981718752f 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/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm index 58590fdac2..274ddc8860 100644 --- a/src/tools/msvc/MSBuildProject.pm +++ b/src/tools/msvc/MSBuildProject.pm @@ -310,10 +310,18 @@ sub WriteItemDefinitionGroup : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary'); my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ';'); - my $targetmachine = - $self->{platform} eq 'Win32' ? 'MachineX86' : 'MachineX64'; - my $arch = - $self->{platform} eq 'Win32' ? 'x86' : 'x86_64'; + my $targetmachine; + my $arch; + if ($self->{platform} eq 'Win32') { + $targetmachine = 'MachineX86'; + $arch = 'x86'; + } elsif ($self->{platform} eq 'ARM64'){ + $targetmachine = 'MachineARM64'; + $arch = 'aarch64'; + } else { + $targetmachine = 'MachineX64'; + $arch = 'x86_64'; + } my $includes = join ';', @{ $self->{includes} }, ""; diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index 7e52e9ad0a..c6e8e91f5f 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -123,8 +123,13 @@ sub mkvcbuild if ($vsVersion >= '9.00') { - push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); - push(@pgportfiles, 'pg_crc32c_sse42.c'); + if ($solution->{platform} eq 'ARM64') { + push(@pgportfiles, 'pg_crc32c_armv8_choose.c'); + push(@pgportfiles, 'pg_crc32c_armv8.c'); + } else { + push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); + push(@pgportfiles, 'pg_crc32c_sse42.c'); + } push(@pgportfiles, 'pg_crc32c_sb8.c'); } else diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm index c2acb58df0..891b7c5f5a 100644 --- a/src/tools/msvc/Solution.pm +++ b/src/tools/msvc/Solution.pm @@ -67,8 +67,13 @@ sub DeterminePlatform # Examine CL help output to determine if we are in 32 or 64-bit mode. my $output = `cl /help 2>&1`; $? >> 8 == 0 or die "cl command not found"; - $self->{platform} = - ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32'; + if ($output =~ /^\/favor:<.+AMD64/m) { + $self->{platform} = 'x64'; + } elsif($output =~ /for ARM64$/m) { + $self->{platform} = 'ARM64'; + } else { + $self->{platform} = 'Win32'; + } } else { @@ -423,7 +428,7 @@ sub GenerateFiles STDC_HEADERS => 1, STRERROR_R_INT => undef, USE_ARMV8_CRC32C => undef, - USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => undef, + USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => 1, USE_ASSERT_CHECKING => $self->{options}->{asserts} ? 1 : undef, USE_BONJOUR => undef, USE_BSD_AUTH => undef, diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl index d6bed1ce15..ad1cf86ebd 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 ne "x86"); # 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: 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; -- 2.38.1 Attachments: [text/plain] v4-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch (7.4K, ../../[email protected]/2-v4-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch) download | inline diff: From 872f538f6261b36a32cbcecae82e99778b747799 Mon Sep 17 00:00:00 2001 From: Niyas Sait <[email protected]> Date: Tue, 22 Feb 2022 13:07:24 +0000 Subject: [PATCH v4] Enable postgres native build for windows-arm64 platform Following changes are included - Extend MSVC scripts to handle ARM64 platform - Add arm64 definition of spin_delay function - Exclude arm_acle.h import for MSVC - Add support for meson build --- meson.build | 33 +++++++++++++++++++------------- src/include/storage/s_lock.h | 10 +++++++++- src/port/pg_crc32c_armv8.c | 2 ++ src/tools/msvc/MSBuildProject.pm | 16 ++++++++++++---- src/tools/msvc/Mkvcbuild.pm | 9 +++++++-- src/tools/msvc/Solution.pm | 11 ++++++++--- src/tools/msvc/gendef.pl | 8 ++++---- 7 files changed, 62 insertions(+), 27 deletions(-) diff --git a/meson.build b/meson.build index 725e10d815..e354ad7650 100644 --- a/meson.build +++ b/meson.build @@ -1944,7 +1944,13 @@ int main(void) elif host_cpu == 'arm' or host_cpu == 'aarch64' - prog = ''' + if cc.get_id() == 'msvc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + else + + prog = ''' #include <arm_acle.h> int main(void) @@ -1960,18 +1966,19 @@ int main(void) } ''' - if 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) - have_optimized_crc = true - elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', - args: test_c_args + ['-march=armv8-a+crc']) - # Use ARM CRC Extension, with runtime check - cflags_crc += '-march=armv8-a+crc' - cdata.set('USE_ARMV8_CRC32C', false) - cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) - have_optimized_crc = true + if 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) + have_optimized_crc = true + elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', + args: test_c_args + ['-march=armv8-a+crc']) + # Use ARM CRC Extension, with runtime check + cflags_crc += '-march=armv8-a+crc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + endif endif endif diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index 8b19ab160f..bf6a6dba35 100644 --- a/src/include/storage/s_lock.h +++ b/src/include/storage/s_lock.h @@ -708,13 +708,21 @@ 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. + * Use _mm_pause (x64) or __isb(arm64) intrinsic instead of rep nop. */ #if defined(_WIN64) static __forceinline void spin_delay(void) { +#ifdef _M_ARM64 + /* + * arm64 way of hinting processor for spin loops optimisations + * ref: https://community.arm.com/support-forums/f/infrastructure-solutions-forum/48654/ssetoneon-faq + */ + __isb(_ARM64_BARRIER_SY); +#else _mm_pause(); +#endif } #else static __forceinline void diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c index 9e301f96f6..981718752f 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/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm index 58590fdac2..274ddc8860 100644 --- a/src/tools/msvc/MSBuildProject.pm +++ b/src/tools/msvc/MSBuildProject.pm @@ -310,10 +310,18 @@ sub WriteItemDefinitionGroup : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary'); my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ';'); - my $targetmachine = - $self->{platform} eq 'Win32' ? 'MachineX86' : 'MachineX64'; - my $arch = - $self->{platform} eq 'Win32' ? 'x86' : 'x86_64'; + my $targetmachine; + my $arch; + if ($self->{platform} eq 'Win32') { + $targetmachine = 'MachineX86'; + $arch = 'x86'; + } elsif ($self->{platform} eq 'ARM64'){ + $targetmachine = 'MachineARM64'; + $arch = 'aarch64'; + } else { + $targetmachine = 'MachineX64'; + $arch = 'x86_64'; + } my $includes = join ';', @{ $self->{includes} }, ""; diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index 7e52e9ad0a..c6e8e91f5f 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -123,8 +123,13 @@ sub mkvcbuild if ($vsVersion >= '9.00') { - push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); - push(@pgportfiles, 'pg_crc32c_sse42.c'); + if ($solution->{platform} eq 'ARM64') { + push(@pgportfiles, 'pg_crc32c_armv8_choose.c'); + push(@pgportfiles, 'pg_crc32c_armv8.c'); + } else { + push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); + push(@pgportfiles, 'pg_crc32c_sse42.c'); + } push(@pgportfiles, 'pg_crc32c_sb8.c'); } else diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm index c2acb58df0..891b7c5f5a 100644 --- a/src/tools/msvc/Solution.pm +++ b/src/tools/msvc/Solution.pm @@ -67,8 +67,13 @@ sub DeterminePlatform # Examine CL help output to determine if we are in 32 or 64-bit mode. my $output = `cl /help 2>&1`; $? >> 8 == 0 or die "cl command not found"; - $self->{platform} = - ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32'; + if ($output =~ /^\/favor:<.+AMD64/m) { + $self->{platform} = 'x64'; + } elsif($output =~ /for ARM64$/m) { + $self->{platform} = 'ARM64'; + } else { + $self->{platform} = 'Win32'; + } } else { @@ -423,7 +428,7 @@ sub GenerateFiles STDC_HEADERS => 1, STRERROR_R_INT => undef, USE_ARMV8_CRC32C => undef, - USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => undef, + USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => 1, USE_ASSERT_CHECKING => $self->{options}->{asserts} ? 1 : undef, USE_BONJOUR => undef, USE_BSD_AUTH => undef, diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl index d6bed1ce15..ad1cf86ebd 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 ne "x86"); # 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: 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; -- 2.38.1 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-02 05:02 Michael Paquier <[email protected]> parent: Niyas Sait <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-12-02 05:02 UTC (permalink / raw) To: Niyas Sait <[email protected]>; +Cc: Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Thu, Dec 01, 2022 at 05:53:47PM +0000, Niyas Sait wrote: > I've attached a new revision of the patch (v4) and includes following > changes, > > 1. Add support for meson build system > 2. Extend MSVC scripts to handle ARM64 platform. > 3. Add arm64 definition of spin_delay function. > 4. Exclude arm_acle.h import with MSVC compiler. > > V3->V4: Add support for meson build system > V2->V3: Removed ASLR enablement and rebased on master. > V1->V2: Rebased on top of master Thanks for the updated version. I have been looking at it closely and it looks like it should be able to do the job (no arm64 machine for Windows here, sigh). I have one tiny comment about this part: - USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => undef, + USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => 1, Shouldn't we only enable this flag when we are under aarch64? Similarly, I don't think that it is a good idea to switch on USE_SSE42_CRC32C_WITH_RUNTIME_CHECK all the time. We should only set it when building under x86 and x86_64. I would also add your link [1] in s_lock.h. [1]: https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics#BarrierRestrictions -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../Y4mG%[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-02 05:41 John Naylor <[email protected]> parent: Niyas Sait <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: John Naylor @ 2022-12-02 05:41 UTC (permalink / raw) To: Niyas Sait <[email protected]>; +Cc: Michael Paquier <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Fri, Dec 2, 2022 at 12:20 AM Niyas Sait <[email protected]> wrote: > > > On 07/11/2022 06:58, Michael Paquier wrote: > > Seems so. Hmm, where does _ARM64_BARRIER_SY come from? Perhaps it > > would be better to have a comment referring to it from a different > > place than the forums of arm, like some actual docs? > > > _ARM64_BARRIER_SY is defined in Microsoft Arm64 intrinsic documentation > - > https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics?view=msvc-170#BarrierRestrictions In particular, at the bottom of that section: "For the __isb intrinsic, the only restriction that is currently valid is _ARM64_BARRIER_SY; all other values are reserved by the architecture." This corresponds to https://developer.arm.com/documentation/ddi0596/2021-06/Base-Instructions/ISB--Instruction-Synchroni...- which says "SY Full system barrier operation, encoded as CRm = 0b1111. Can be omitted." > I couldn't find something more official for the sse2neon library part. Not quite sure what this is referring to, but it seems we can just point to the __aarch64__ section in the same file, which uses the same instruction: spin_delay(void) { __asm__ __volatile__( " isb; \n"); } ...and which already explains the choice with a comment. About v4: + * Use _mm_pause (x64) or __isb(arm64) intrinsic instead of rep nop. Need a space here after __isb. + if cc.get_id() == 'msvc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + else That seems like a heavy-handed way to force it. Could we just use the same gating in the test program that the patch puts in the code of interest? Namely: +#ifndef _MSC_VER #include <arm_acle.h> +#endif -- John Naylor EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-02 09:37 Niyas Sait <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 0 replies; 90+ messages in thread From: Niyas Sait @ 2022-12-02 09:37 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On 02/12/2022 05:02, Michael Paquier wrote: > Thanks for the updated version. I have been looking at it closely and > it looks like it should be able to do the job (no arm64 machine for > Windows here, sigh). > > I have one tiny comment about this part: > > - USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => undef, > + USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => 1, > > Shouldn't we only enable this flag when we are under aarch64? > Similarly, I don't think that it is a good idea to switch on > USE_SSE42_CRC32C_WITH_RUNTIME_CHECK all the time. We should only set > it when building under x86 and x86_64. > Ok, I will fix ARM64 specific one in the next revision. -- Niyas ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-02 09:50 Niyas Sait <[email protected]> parent: John Naylor <[email protected]> 0 siblings, 0 replies; 90+ messages in thread From: Niyas Sait @ 2022-12-02 09:50 UTC (permalink / raw) To: John Naylor <[email protected]>; +Cc: Michael Paquier <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On 02/12/2022 05:41, John Naylor wrote: >> I couldn't find something more official for the sse2neon library part. > Not quite sure what this is referring to, but it seems we can just point to > the __aarch64__ section in the same file, which uses the same instruction: > > spin_delay(void) > { > __asm__ __volatile__( > " isb; \n"); > } > > ...and which already explains the choice with a comment. Good point. Will add the comment. > + if cc.get_id() == 'msvc' > + cdata.set('USE_ARMV8_CRC32C', false) > + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) > + have_optimized_crc = true > + else > > That seems like a heavy-handed way to force it. Could we just use the same > gating in the test program that the patch puts in the code of interest? > Namely: > > +#ifndef _MSC_VER > #include <arm_acle.h> > +#endif I took a similar approach as x86 MSVC code. I don't think the test program would work with MSVC. The compiler options are not MSVC friendly. -- Niyas ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-02 11:09 Niyas Sait <[email protected]> parent: Niyas Sait <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Niyas Sait @ 2022-12-02 11:09 UTC (permalink / raw) To: Michael Paquier <[email protected]>; Andres Freund <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hello, I've attached a new revision of the patch (v5) and includes following changes, 1. Add support for meson build system 2. Extend MSVC scripts to handle ARM64 platform. 3. Add arm64 definition of spin_delay function. 4. Exclude arm_acle.h import with MSVC compiler. V4->V5: * Added reference to Microsoft arm64 intrinsic documentation * Conditionally enable USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK * Fixed styling issue spotted by Ian Lawerence Barwick V3->V4: Add support for meson build system V2->V3: Removed ASLR enablement and rebased on master. V1->V2: Rebased on top of master -- Niyas From 58b82107088456fc71d239f4e1b995d91a94b4ef Mon Sep 17 00:00:00 2001 From: Niyas Sait <[email protected]> Date: Tue, 22 Feb 2022 13:07:24 +0000 Subject: [PATCH v5] Enable postgres native build for windows-arm64 platform Following changes are included - Extend MSVC scripts to handle ARM64 platform - Add arm64 definition of spin_delay function - Exclude arm_acle.h import for MSVC - Add support for meson build --- meson.build | 33 +++++++++++++++++++------------- src/include/storage/s_lock.h | 10 +++++++++- src/port/pg_crc32c_armv8.c | 2 ++ src/tools/msvc/MSBuildProject.pm | 16 ++++++++++++---- src/tools/msvc/Mkvcbuild.pm | 9 +++++++-- src/tools/msvc/Solution.pm | 11 ++++++++--- src/tools/msvc/gendef.pl | 8 ++++---- 7 files changed, 62 insertions(+), 27 deletions(-) diff --git a/meson.build b/meson.build index 725e10d815..e354ad7650 100644 --- a/meson.build +++ b/meson.build @@ -1944,7 +1944,13 @@ int main(void) elif host_cpu == 'arm' or host_cpu == 'aarch64' - prog = ''' + if cc.get_id() == 'msvc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + else + + prog = ''' #include <arm_acle.h> int main(void) @@ -1960,18 +1966,19 @@ int main(void) } ''' - if 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) - have_optimized_crc = true - elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', - args: test_c_args + ['-march=armv8-a+crc']) - # Use ARM CRC Extension, with runtime check - cflags_crc += '-march=armv8-a+crc' - cdata.set('USE_ARMV8_CRC32C', false) - cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) - have_optimized_crc = true + if 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) + have_optimized_crc = true + elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', + args: test_c_args + ['-march=armv8-a+crc']) + # Use ARM CRC Extension, with runtime check + cflags_crc += '-march=armv8-a+crc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + endif endif endif diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index 8b19ab160f..ab6a6e0281 100644 --- a/src/include/storage/s_lock.h +++ b/src/include/storage/s_lock.h @@ -708,13 +708,21 @@ 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. + * Use _mm_pause (x64) or __isb (arm64) intrinsic instead of rep nop. */ #if defined(_WIN64) static __forceinline void spin_delay(void) { +#ifdef _M_ARM64 + /* + * See spin_delay aarch64 inline assembly definition above for details + * ref: https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics#BarrierRestrictions + */ + __isb(_ARM64_BARRIER_SY); +#else _mm_pause(); +#endif } #else static __forceinline void diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c index 9e301f96f6..981718752f 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/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm index 58590fdac2..274ddc8860 100644 --- a/src/tools/msvc/MSBuildProject.pm +++ b/src/tools/msvc/MSBuildProject.pm @@ -310,10 +310,18 @@ sub WriteItemDefinitionGroup : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary'); my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ';'); - my $targetmachine = - $self->{platform} eq 'Win32' ? 'MachineX86' : 'MachineX64'; - my $arch = - $self->{platform} eq 'Win32' ? 'x86' : 'x86_64'; + my $targetmachine; + my $arch; + if ($self->{platform} eq 'Win32') { + $targetmachine = 'MachineX86'; + $arch = 'x86'; + } elsif ($self->{platform} eq 'ARM64'){ + $targetmachine = 'MachineARM64'; + $arch = 'aarch64'; + } else { + $targetmachine = 'MachineX64'; + $arch = 'x86_64'; + } my $includes = join ';', @{ $self->{includes} }, ""; diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index 7e52e9ad0a..c6e8e91f5f 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -123,8 +123,13 @@ sub mkvcbuild if ($vsVersion >= '9.00') { - push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); - push(@pgportfiles, 'pg_crc32c_sse42.c'); + if ($solution->{platform} eq 'ARM64') { + push(@pgportfiles, 'pg_crc32c_armv8_choose.c'); + push(@pgportfiles, 'pg_crc32c_armv8.c'); + } else { + push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); + push(@pgportfiles, 'pg_crc32c_sse42.c'); + } push(@pgportfiles, 'pg_crc32c_sb8.c'); } else diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm index c2acb58df0..5eb4ccb8ff 100644 --- a/src/tools/msvc/Solution.pm +++ b/src/tools/msvc/Solution.pm @@ -67,8 +67,13 @@ sub DeterminePlatform # Examine CL help output to determine if we are in 32 or 64-bit mode. my $output = `cl /help 2>&1`; $? >> 8 == 0 or die "cl command not found"; - $self->{platform} = - ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32'; + if ($output =~ /^\/favor:<.+AMD64/m) { + $self->{platform} = 'x64'; + } elsif($output =~ /for ARM64$/m) { + $self->{platform} = 'ARM64'; + } else { + $self->{platform} = 'Win32'; + } } else { @@ -423,7 +428,7 @@ sub GenerateFiles STDC_HEADERS => 1, STRERROR_R_INT => undef, USE_ARMV8_CRC32C => undef, - USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => undef, + USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => $self->{platform} eq "ARM64" ? : 1 : undef, USE_ASSERT_CHECKING => $self->{options}->{asserts} ? 1 : undef, USE_BONJOUR => undef, USE_BSD_AUTH => undef, diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl index d6bed1ce15..ad1cf86ebd 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 ne "x86"); # 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: 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; -- 2.38.1.windows.1 Attachments: [text/plain] v5-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch (7.4K, ../../[email protected]/2-v5-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch) download | inline diff: From 58b82107088456fc71d239f4e1b995d91a94b4ef Mon Sep 17 00:00:00 2001 From: Niyas Sait <[email protected]> Date: Tue, 22 Feb 2022 13:07:24 +0000 Subject: [PATCH v5] Enable postgres native build for windows-arm64 platform Following changes are included - Extend MSVC scripts to handle ARM64 platform - Add arm64 definition of spin_delay function - Exclude arm_acle.h import for MSVC - Add support for meson build --- meson.build | 33 +++++++++++++++++++------------- src/include/storage/s_lock.h | 10 +++++++++- src/port/pg_crc32c_armv8.c | 2 ++ src/tools/msvc/MSBuildProject.pm | 16 ++++++++++++---- src/tools/msvc/Mkvcbuild.pm | 9 +++++++-- src/tools/msvc/Solution.pm | 11 ++++++++--- src/tools/msvc/gendef.pl | 8 ++++---- 7 files changed, 62 insertions(+), 27 deletions(-) diff --git a/meson.build b/meson.build index 725e10d815..e354ad7650 100644 --- a/meson.build +++ b/meson.build @@ -1944,7 +1944,13 @@ int main(void) elif host_cpu == 'arm' or host_cpu == 'aarch64' - prog = ''' + if cc.get_id() == 'msvc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + else + + prog = ''' #include <arm_acle.h> int main(void) @@ -1960,18 +1966,19 @@ int main(void) } ''' - if 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) - have_optimized_crc = true - elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', - args: test_c_args + ['-march=armv8-a+crc']) - # Use ARM CRC Extension, with runtime check - cflags_crc += '-march=armv8-a+crc' - cdata.set('USE_ARMV8_CRC32C', false) - cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) - have_optimized_crc = true + if 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) + have_optimized_crc = true + elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', + args: test_c_args + ['-march=armv8-a+crc']) + # Use ARM CRC Extension, with runtime check + cflags_crc += '-march=armv8-a+crc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + endif endif endif diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index 8b19ab160f..ab6a6e0281 100644 --- a/src/include/storage/s_lock.h +++ b/src/include/storage/s_lock.h @@ -708,13 +708,21 @@ 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. + * Use _mm_pause (x64) or __isb (arm64) intrinsic instead of rep nop. */ #if defined(_WIN64) static __forceinline void spin_delay(void) { +#ifdef _M_ARM64 + /* + * See spin_delay aarch64 inline assembly definition above for details + * ref: https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics#BarrierRestrictions + */ + __isb(_ARM64_BARRIER_SY); +#else _mm_pause(); +#endif } #else static __forceinline void diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c index 9e301f96f6..981718752f 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/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm index 58590fdac2..274ddc8860 100644 --- a/src/tools/msvc/MSBuildProject.pm +++ b/src/tools/msvc/MSBuildProject.pm @@ -310,10 +310,18 @@ sub WriteItemDefinitionGroup : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary'); my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ';'); - my $targetmachine = - $self->{platform} eq 'Win32' ? 'MachineX86' : 'MachineX64'; - my $arch = - $self->{platform} eq 'Win32' ? 'x86' : 'x86_64'; + my $targetmachine; + my $arch; + if ($self->{platform} eq 'Win32') { + $targetmachine = 'MachineX86'; + $arch = 'x86'; + } elsif ($self->{platform} eq 'ARM64'){ + $targetmachine = 'MachineARM64'; + $arch = 'aarch64'; + } else { + $targetmachine = 'MachineX64'; + $arch = 'x86_64'; + } my $includes = join ';', @{ $self->{includes} }, ""; diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index 7e52e9ad0a..c6e8e91f5f 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -123,8 +123,13 @@ sub mkvcbuild if ($vsVersion >= '9.00') { - push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); - push(@pgportfiles, 'pg_crc32c_sse42.c'); + if ($solution->{platform} eq 'ARM64') { + push(@pgportfiles, 'pg_crc32c_armv8_choose.c'); + push(@pgportfiles, 'pg_crc32c_armv8.c'); + } else { + push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); + push(@pgportfiles, 'pg_crc32c_sse42.c'); + } push(@pgportfiles, 'pg_crc32c_sb8.c'); } else diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm index c2acb58df0..5eb4ccb8ff 100644 --- a/src/tools/msvc/Solution.pm +++ b/src/tools/msvc/Solution.pm @@ -67,8 +67,13 @@ sub DeterminePlatform # Examine CL help output to determine if we are in 32 or 64-bit mode. my $output = `cl /help 2>&1`; $? >> 8 == 0 or die "cl command not found"; - $self->{platform} = - ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32'; + if ($output =~ /^\/favor:<.+AMD64/m) { + $self->{platform} = 'x64'; + } elsif($output =~ /for ARM64$/m) { + $self->{platform} = 'ARM64'; + } else { + $self->{platform} = 'Win32'; + } } else { @@ -423,7 +428,7 @@ sub GenerateFiles STDC_HEADERS => 1, STRERROR_R_INT => undef, USE_ARMV8_CRC32C => undef, - USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => undef, + USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => $self->{platform} eq "ARM64" ? : 1 : undef, USE_ASSERT_CHECKING => $self->{options}->{asserts} ? 1 : undef, USE_BONJOUR => undef, USE_BSD_AUTH => undef, diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl index d6bed1ce15..ad1cf86ebd 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 ne "x86"); # 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: 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; -- 2.38.1.windows.1 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-05 05:12 Michael Paquier <[email protected]> parent: Niyas Sait <[email protected]> 0 siblings, 2 replies; 90+ messages in thread From: Michael Paquier @ 2022-12-05 05:12 UTC (permalink / raw) To: Niyas Sait <[email protected]>; +Cc: Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Fri, Dec 02, 2022 at 11:09:15AM +0000, Niyas Sait wrote: > I've attached a new revision of the patch (v5) and includes following > changes, > > 1. Add support for meson build system > 2. Extend MSVC scripts to handle ARM64 platform. > 3. Add arm64 definition of spin_delay function. > 4. Exclude arm_acle.h import with MSVC compiler. Hmm. There are still a few things that need some attention here: - USE_SSE42_CRC32C_WITH_RUNTIME_CHECK should not be set for aarch64. - This is missing updates for ICU. Looking at the upstream code, Build.Windows.ProjectConfiguration.props uses libARM64 and binARM64 for the output library and binary paths. - This is missing updates for krb5. For this case, I am seeing no traces of packages for aarch64, so I guess that we could just fail hard until someone cares enough to ping us about what to do here. - There were zero changes in the docs, but we need to update at least the section about architectures supported for the 64-bit builds. - Last comes OpenSSL, that supports amd64_arm64 as build target (see NOTES-WINDOWS.md), and the library names are libssl.lib and libcrypto.lib. Looking at https://slproweb.com/products/Win32OpenSSL.html, there are experimental builds for arm64 with OpenSSL 3.0. Niyas or somebody else, could you look at the contents of lib/VC/ and see what we could rely on for the debug builds after installing this MSI? We should rely on something like lib/VC/sslcrypto64MD.lib or lib/VC/sslcrypto32MD.lib, but for arm64. With meson gaining in maturity, perhaps that's not the most urgent thing as we will likely remove src/tools/msvc/ soon but I'd rather do that right anyway as much as I can to avoid an incorrect state in the tree at any time in its history. - USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => undef, + USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => $self->{platform} eq "ARM64" ? : 1 : undef, Did you actually test this patch? This won't work at all with perl, per se the double colon after the question mark. For now, please find attached an updated patch with all the fixes I could come up with. -- Michael Attachments: [text/x-diff] v6-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch (9.6K, ../../[email protected]/2-v6-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch) download | inline diff: From 9cb858cfdb25c3a119a8b28321cf3218eac282c5 Mon Sep 17 00:00:00 2001 From: Michael Paquier <[email protected]> Date: Mon, 5 Dec 2022 14:09:29 +0900 Subject: [PATCH v6] Enable postgres native build for windows-arm64 platform Following changes are included - Extend MSVC scripts to handle ARM64 platform - Add arm64 definition of spin_delay function - Exclude arm_acle.h import for MSVC - Add support for meson build --- src/include/storage/s_lock.h | 10 +++++++++- src/port/pg_crc32c_armv8.c | 2 ++ doc/src/sgml/install-windows.sgml | 3 ++- meson.build | 33 +++++++++++++++++++------------ src/tools/msvc/MSBuildProject.pm | 16 +++++++++++---- src/tools/msvc/Mkvcbuild.pm | 9 +++++++-- src/tools/msvc/Solution.pm | 30 ++++++++++++++++++++++------ src/tools/msvc/gendef.pl | 8 ++++---- 8 files changed, 80 insertions(+), 31 deletions(-) diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index 8b19ab160f..ab6a6e0281 100644 --- a/src/include/storage/s_lock.h +++ b/src/include/storage/s_lock.h @@ -708,13 +708,21 @@ 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. + * Use _mm_pause (x64) or __isb (arm64) intrinsic instead of rep nop. */ #if defined(_WIN64) static __forceinline void spin_delay(void) { +#ifdef _M_ARM64 + /* + * See spin_delay aarch64 inline assembly definition above for details + * ref: https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics#BarrierRestrictions + */ + __isb(_ARM64_BARRIER_SY); +#else _mm_pause(); +#endif } #else static __forceinline void diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c index 9e301f96f6..981718752f 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/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml index bbd4960e7b..3f865d7d3b 100644 --- a/doc/src/sgml/install-windows.sgml +++ b/doc/src/sgml/install-windows.sgml @@ -352,7 +352,8 @@ $ENV{MSBFLAGS}="/m"; <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 architectures on 64-bit + Windows. </para> <para> diff --git a/meson.build b/meson.build index 725e10d815..e354ad7650 100644 --- a/meson.build +++ b/meson.build @@ -1944,7 +1944,13 @@ int main(void) elif host_cpu == 'arm' or host_cpu == 'aarch64' - prog = ''' + if cc.get_id() == 'msvc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + else + + prog = ''' #include <arm_acle.h> int main(void) @@ -1960,18 +1966,19 @@ int main(void) } ''' - if 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) - have_optimized_crc = true - elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', - args: test_c_args + ['-march=armv8-a+crc']) - # Use ARM CRC Extension, with runtime check - cflags_crc += '-march=armv8-a+crc' - cdata.set('USE_ARMV8_CRC32C', false) - cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) - have_optimized_crc = true + if 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) + have_optimized_crc = true + elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', + args: test_c_args + ['-march=armv8-a+crc']) + # Use ARM CRC Extension, with runtime check + cflags_crc += '-march=armv8-a+crc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + endif endif endif diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm index 58590fdac2..274ddc8860 100644 --- a/src/tools/msvc/MSBuildProject.pm +++ b/src/tools/msvc/MSBuildProject.pm @@ -310,10 +310,18 @@ sub WriteItemDefinitionGroup : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary'); my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ';'); - my $targetmachine = - $self->{platform} eq 'Win32' ? 'MachineX86' : 'MachineX64'; - my $arch = - $self->{platform} eq 'Win32' ? 'x86' : 'x86_64'; + my $targetmachine; + my $arch; + if ($self->{platform} eq 'Win32') { + $targetmachine = 'MachineX86'; + $arch = 'x86'; + } elsif ($self->{platform} eq 'ARM64'){ + $targetmachine = 'MachineARM64'; + $arch = 'aarch64'; + } else { + $targetmachine = 'MachineX64'; + $arch = 'x86_64'; + } my $includes = join ';', @{ $self->{includes} }, ""; diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index 7e52e9ad0a..c6e8e91f5f 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -123,8 +123,13 @@ sub mkvcbuild if ($vsVersion >= '9.00') { - push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); - push(@pgportfiles, 'pg_crc32c_sse42.c'); + if ($solution->{platform} eq 'ARM64') { + push(@pgportfiles, 'pg_crc32c_armv8_choose.c'); + push(@pgportfiles, 'pg_crc32c_armv8.c'); + } else { + push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); + push(@pgportfiles, 'pg_crc32c_sse42.c'); + } push(@pgportfiles, 'pg_crc32c_sb8.c'); } else diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm index c2acb58df0..f7a5c83c8f 100644 --- a/src/tools/msvc/Solution.pm +++ b/src/tools/msvc/Solution.pm @@ -67,8 +67,13 @@ sub DeterminePlatform # Examine CL help output to determine if we are in 32 or 64-bit mode. my $output = `cl /help 2>&1`; $? >> 8 == 0 or die "cl command not found"; - $self->{platform} = - ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32'; + if ($output =~ /^\/favor:<.+AMD64/m) { + $self->{platform} = 'x64'; + } elsif($output =~ /for ARM64$/m) { + $self->{platform} = 'ARM64'; + } else { + $self->{platform} = 'Win32'; + } } else { @@ -423,7 +428,8 @@ sub GenerateFiles STDC_HEADERS => 1, STRERROR_R_INT => undef, USE_ARMV8_CRC32C => undef, - USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => undef, + USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => + ($self->{platform} eq "ARM64") ? 1 : undef, USE_ASSERT_CHECKING => $self->{options}->{asserts} ? 1 : undef, USE_BONJOUR => undef, USE_BSD_AUTH => undef, @@ -438,7 +444,8 @@ sub GenerateFiles USE_PAM => undef, USE_SLICING_BY_8_CRC32C => undef, USE_SSE42_CRC32C => undef, - USE_SSE42_CRC32C_WITH_RUNTIME_CHECK => 1, + USE_SSE42_CRC32C_WITH_RUNTIME_CHECK => + ($self->{platform} eq "x64" || $self->{platform} eq "Win32") ? 1 : undef, USE_SYSTEMD => undef, USE_SYSV_SEMAPHORES => undef, USE_SYSV_SHARED_MEMORY => undef, @@ -1013,7 +1020,7 @@ sub AddProject $proj->AddLibrary( $self->{options}->{gss} . '\lib\i386\gssapi32.lib'); } - else + elsif ($self->{platform} eq 'x64') { $proj->AddLibrary( $self->{options}->{gss} . '\lib\amd64\krb5_64.lib'); @@ -1022,6 +1029,10 @@ sub AddProject $proj->AddLibrary( $self->{options}->{gss} . '\lib\amd64\gssapi64.lib'); } + else + { + die "Kerberos not supported with ARM64\n"; + } } if ($self->{options}->{iconv}) { @@ -1037,12 +1048,19 @@ sub AddProject $proj->AddLibrary($self->{options}->{icu} . '\lib\icuuc.lib'); $proj->AddLibrary($self->{options}->{icu} . '\lib\icudt.lib'); } - else + elsif ($self->{platform} eq 'x64') { $proj->AddLibrary($self->{options}->{icu} . '\lib64\icuin.lib'); $proj->AddLibrary($self->{options}->{icu} . '\lib64\icuuc.lib'); $proj->AddLibrary($self->{options}->{icu} . '\lib64\icudt.lib'); } + else + { + # aarch64. + $proj->AddLibrary($self->{options}->{icu} . '\libARM64\icuin.lib'); + $proj->AddLibrary($self->{options}->{icu} . '\libARM64\icuuc.lib'); + $proj->AddLibrary($self->{options}->{icu} . '\libARM64\icudt.lib'); + } } if ($self->{options}->{xml}) { diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl index d6bed1ce15..4882d37faf 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: 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; -- 2.38.1 [application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-05 08:54 Niyas Sait <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 0 replies; 90+ messages in thread From: Niyas Sait @ 2022-12-05 08:54 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On 05/12/2022 05:12, Michael Paquier wrote: > - Last comes OpenSSL, that supports amd64_arm64 as build target (see > NOTES-WINDOWS.md), and the library names are libssl.lib and > libcrypto.lib. Looking at > https://slproweb.com/products/Win32OpenSSL.html, there are > experimental builds for arm64 with OpenSSL 3.0. Niyas or somebody > else, could you look at the contents of lib/VC/ and see what we could > rely on for the debug builds after installing this MSI? We should > rely on something like lib/VC/sslcrypto64MD.lib or > lib/VC/sslcrypto32MD.lib, but for arm64. I tried that installer. And I can see following libraries installed in lib/VC location. libcryptoarm64MD.lib libcryptoarm64MDd.lib libcryptoarm64MT.lib libcryptoarm64MTd.lib libsslarm64MD.lib libsslarm64MDd.lib libsslarm64MT.lib libsslarm64MTd.lib > - USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => undef, > + USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK => $self->{platform} eq "ARM64" ? : 1 : undef, > Did you actually test this patch? This won't work at all with perl, > per se the double colon after the question mark. Yes I did a full build. I am not sure why I didn't see any error with that. My perl skills are very limited and I started with something bit more naive like "$self->{platform} == "ARM64" ? : 1 : undef" But that didn't work and I changed to using eq and the compilation was fine. Thanks for fixing the patch. > For now, please find attached an updated patch with all the fixes I > could come up with. Thanks. I did a quick sanity build with your updated patch and looks fine. -- Niyas ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-05 18:14 Andres Freund <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 2 replies; 90+ messages in thread From: Andres Freund @ 2022-12-05 18:14 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 2022-12-05 14:12:41 +0900, Michael Paquier wrote: > With meson gaining in maturity, perhaps that's not the most urgent > thing as we will likely remove src/tools/msvc/ soon but I'd rather do > that right anyway as much as I can to avoid an incorrect state in the > tree at any time in its history. I'd actually argue that we should just not add win32 support to src/tools/msvc/. > --- a/src/include/storage/s_lock.h > +++ b/src/include/storage/s_lock.h > @@ -708,13 +708,21 @@ 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. > + * Use _mm_pause (x64) or __isb (arm64) intrinsic instead of rep nop. > */ > #if defined(_WIN64) > static __forceinline void > spin_delay(void) > { > +#ifdef _M_ARM64 > + /* > + * See spin_delay aarch64 inline assembly definition above for details > + * ref: https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics#BarrierRestrictions > + */ > + __isb(_ARM64_BARRIER_SY); > +#else > _mm_pause(); > +#endif > } > #else > static __forceinline void This looks somewhat wrong to me. We end up with some ifdefs on the function defintion level, and some others inside the function body. I think it should be either or. > diff --git a/meson.build b/meson.build > index 725e10d815..e354ad7650 100644 > --- a/meson.build > +++ b/meson.build > @@ -1944,7 +1944,13 @@ int main(void) > > elif host_cpu == 'arm' or host_cpu == 'aarch64' > > - prog = ''' > + if cc.get_id() == 'msvc' > + cdata.set('USE_ARMV8_CRC32C', false) > + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) > + have_optimized_crc = true > + else > + > + prog = ''' > #include <arm_acle.h> > > int main(void) Why does this need to be hardcoded? The compiler probe should just work for msvc. > @@ -1960,18 +1966,19 @@ int main(void) > } > ''' > > - if 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) > - have_optimized_crc = true > - elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', > - args: test_c_args + ['-march=armv8-a+crc']) > - # Use ARM CRC Extension, with runtime check > - cflags_crc += '-march=armv8-a+crc' > - cdata.set('USE_ARMV8_CRC32C', false) > - cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) > - have_optimized_crc = true > + if 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) > + have_optimized_crc = true > + elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', > + args: test_c_args + ['-march=armv8-a+crc']) > + # Use ARM CRC Extension, with runtime check > + cflags_crc += '-march=armv8-a+crc' > + cdata.set('USE_ARMV8_CRC32C', false) > + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) > + have_optimized_crc = true > + endif > endif > endif And then this reindent wouldn't be needed. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-05 23:31 Michael Paquier <[email protected]> parent: Andres Freund <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-12-05 23:31 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Mon, Dec 05, 2022 at 10:14:49AM -0800, Andres Freund wrote: > On 2022-12-05 14:12:41 +0900, Michael Paquier wrote: >> With meson gaining in maturity, perhaps that's not the most urgent >> thing as we will likely remove src/tools/msvc/ soon but I'd rather do >> that right anyway as much as I can to avoid an incorrect state in the >> tree at any time in its history. > > I'd actually argue that we should just not add win32 support to > src/tools/msvc/. Are you arguing about ripping out the existing win32 or do nothing for arm64? I guess the later, but these words also sound like the former to me. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../Y45%[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-05 23:48 Andres Freund <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andres Freund @ 2022-12-05 23:48 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 2022-12-06 08:31:16 +0900, Michael Paquier wrote: > On Mon, Dec 05, 2022 at 10:14:49AM -0800, Andres Freund wrote: > > On 2022-12-05 14:12:41 +0900, Michael Paquier wrote: > >> With meson gaining in maturity, perhaps that's not the most urgent > >> thing as we will likely remove src/tools/msvc/ soon but I'd rather do > >> that right anyway as much as I can to avoid an incorrect state in the > >> tree at any time in its history. > > > > I'd actually argue that we should just not add win32 support to > > src/tools/msvc/. > > Are you arguing about ripping out the existing win32 or do nothing for > arm64? I guess the later, but these words also sound like the former > to me. Yes, that's a typo. I meant that we shouldn't add arm64 support to src/tools/msvc/. I do think we should rip out src/tools/msvc/ soon-ish, but we need buildfarm support first. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-06 00:16 Michael Paquier <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 0 replies; 90+ messages in thread From: Michael Paquier @ 2022-12-06 00:16 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Mon, Dec 05, 2022 at 03:48:45PM -0800, Andres Freund wrote: > Yes, that's a typo. I meant that we shouldn't add arm64 support to > src/tools/msvc/. Okay, thanks. > I do think we should rip out src/tools/msvc/ soon-ish, but we need > buildfarm support first. Sure, let's see where it goes. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-12 13:38 Niyas Sait <[email protected]> parent: Andres Freund <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Niyas Sait @ 2022-12-12 13:38 UTC (permalink / raw) To: Andres Freund <[email protected]>; Michael Paquier <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> Hi, On 05/12/2022 18:14, Andres Freund wrote: >> With meson gaining in maturity, perhaps that's not the most urgent >> thing as we will likely remove src/tools/msvc/ soon but I'd rather do >> that right anyway as much as I can to avoid an incorrect state in the >> tree at any time in its history. > > I'd actually argue that we should just not add win32 support to > src/tools/msvc/. > > I think the old build system specific part is really minimal in the patch. I can strip out those if that's preferred. >> --- a/src/include/storage/s_lock.h >> +++ b/src/include/storage/s_lock.h >> @@ -708,13 +708,21 @@ 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. >> + * Use _mm_pause (x64) or __isb (arm64) intrinsic instead of rep nop. >> */ >> #if defined(_WIN64) >> static __forceinline void >> spin_delay(void) >> { >> +#ifdef _M_ARM64 >> + /* >> + * See spin_delay aarch64 inline assembly definition above for details >> + * ref: https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics#BarrierRestrictions >> + */ >> + __isb(_ARM64_BARRIER_SY); >> +#else >> _mm_pause(); >> +#endif >> } >> #else >> static __forceinline void > > This looks somewhat wrong to me. We end up with some ifdefs on the function > defintion level, and some others inside the function body. I think it should > be either or. > Ok, I can add an MSVC/ARM64 specific function. >> diff --git a/meson.build b/meson.build >> index 725e10d815..e354ad7650 100644 >> --- a/meson.build >> +++ b/meson.build >> @@ -1944,7 +1944,13 @@ int main(void) >> >> elif host_cpu == 'arm' or host_cpu == 'aarch64' >> >> - prog = ''' >> + if cc.get_id() == 'msvc' >> + cdata.set('USE_ARMV8_CRC32C', false) >> + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) >> + have_optimized_crc = true >> + else >> + >> + prog = ''' >> #include <arm_acle.h> >> >> int main(void) > Why does this need to be hardcoded? The compiler probe should just work for > msvc. > There are couple of minor issues in the code probe with MSVC such as arm_acle.h needs to be removed and requires an explicit import of intrin.h. But even with those fixes, USE_ARMV8_CRC32C would be set and no runtime CRC extension check will be performed. Since CRC extension is optional in ARMv8, It would be better to use the CRC variant with runtime check. So I end up following the x64 variant and hardcoded the flags in case of ARM64 and MSVC. -- Niyas ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-12 23:56 Michael Paquier <[email protected]> parent: Niyas Sait <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2022-12-12 23:56 UTC (permalink / raw) To: Niyas Sait <[email protected]>; +Cc: Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On Mon, Dec 12, 2022 at 01:38:37PM +0000, Niyas Sait wrote: > On 05/12/2022 18:14, Andres Freund wrote: > I think the old build system specific part is really minimal in the patch. I > can strip out those if that's preferred. Removing all the changes from src/tools/msvc/ is an approach that works for me. >> Why does this need to be hardcoded? The compiler probe should just work for >> msvc. > > There are couple of minor issues in the code probe with MSVC such as > arm_acle.h needs to be removed and requires an explicit import of intrin.h. > But even with those fixes, USE_ARMV8_CRC32C would be set and no runtime CRC > extension check will be performed. Since CRC extension is optional in ARMv8, > It would be better to use the CRC variant with runtime check. So I end up > following the x64 variant and hardcoded the flags in case of ARM64 and MSVC. Hm.. Andres, do you have access to Windows hosts with ARM64 underneath to validate any of that? No way to blame Cirrus for not having this option, they already do a lot :) -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../Y5e%[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2022-12-16 10:52 Niyas Sait <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 0 replies; 90+ messages in thread From: Niyas Sait @ 2022-12-16 10:52 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]> On 12/12/2022 23:56, Michael Paquier wrote: > On Mon, Dec 12, 2022 at 01:38:37PM +0000, Niyas Sait wrote: >> On 05/12/2022 18:14, Andres Freund wrote: >> I think the old build system specific part is really minimal in the patch. I >> can strip out those if that's preferred. > Removing all the changes from src/tools/msvc/ is an approach that > works for me. > I've attached a new version (v7) that removes changes to support old MSVC build system. -- Niyas From 50e8affb5bcb3f6a50a223053fc92145a5709e82 Mon Sep 17 00:00:00 2001 From: Niyas Sait <[email protected]> Date: Fri, 16 Dec 2022 10:45:56 +0000 Subject: [PATCH v7] Enable postgres native build for windows-arm64 platform - Add support for meson build - Add arm64 definition of spin_delay function - Exclude arm_acle.h import for MSVC --- doc/src/sgml/install-windows.sgml | 3 ++- meson.build | 33 +++++++++++++++++++------------ src/include/storage/s_lock.h | 20 +++++++++++++++++-- src/port/pg_crc32c_armv8.c | 2 ++ src/tools/msvc/gendef.pl | 8 ++++---- 5 files changed, 46 insertions(+), 20 deletions(-) diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml index bbd4960e7b..3f865d7d3b 100644 --- a/doc/src/sgml/install-windows.sgml +++ b/doc/src/sgml/install-windows.sgml @@ -352,7 +352,8 @@ $ENV{MSBFLAGS}="/m"; <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 architectures on 64-bit + Windows. </para> <para> diff --git a/meson.build b/meson.build index 725e10d815..e354ad7650 100644 --- a/meson.build +++ b/meson.build @@ -1944,7 +1944,13 @@ int main(void) elif host_cpu == 'arm' or host_cpu == 'aarch64' - prog = ''' + if cc.get_id() == 'msvc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + else + + prog = ''' #include <arm_acle.h> int main(void) @@ -1960,18 +1966,19 @@ int main(void) } ''' - if 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) - have_optimized_crc = true - elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', - args: test_c_args + ['-march=armv8-a+crc']) - # Use ARM CRC Extension, with runtime check - cflags_crc += '-march=armv8-a+crc' - cdata.set('USE_ARMV8_CRC32C', false) - cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) - have_optimized_crc = true + if 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) + have_optimized_crc = true + elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', + args: test_c_args + ['-march=armv8-a+crc']) + # Use ARM CRC Extension, with runtime check + cflags_crc += '-march=armv8-a+crc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + endif endif endif diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index 8b19ab160f..94d2380393 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 9e301f96f6..981718752f 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 d6bed1ce15..4882d37faf 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: 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; -- 2.38.1.windows.1 Attachments: [text/plain] v7-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch (5.4K, ../../[email protected]/2-v7-0001-Enable-postgres-native-build-for-windows-arm64-pl.patch) download | inline diff: From 50e8affb5bcb3f6a50a223053fc92145a5709e82 Mon Sep 17 00:00:00 2001 From: Niyas Sait <[email protected]> Date: Fri, 16 Dec 2022 10:45:56 +0000 Subject: [PATCH v7] Enable postgres native build for windows-arm64 platform - Add support for meson build - Add arm64 definition of spin_delay function - Exclude arm_acle.h import for MSVC --- doc/src/sgml/install-windows.sgml | 3 ++- meson.build | 33 +++++++++++++++++++------------ src/include/storage/s_lock.h | 20 +++++++++++++++++-- src/port/pg_crc32c_armv8.c | 2 ++ src/tools/msvc/gendef.pl | 8 ++++---- 5 files changed, 46 insertions(+), 20 deletions(-) diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml index bbd4960e7b..3f865d7d3b 100644 --- a/doc/src/sgml/install-windows.sgml +++ b/doc/src/sgml/install-windows.sgml @@ -352,7 +352,8 @@ $ENV{MSBFLAGS}="/m"; <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 architectures on 64-bit + Windows. </para> <para> diff --git a/meson.build b/meson.build index 725e10d815..e354ad7650 100644 --- a/meson.build +++ b/meson.build @@ -1944,7 +1944,13 @@ int main(void) elif host_cpu == 'arm' or host_cpu == 'aarch64' - prog = ''' + if cc.get_id() == 'msvc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + else + + prog = ''' #include <arm_acle.h> int main(void) @@ -1960,18 +1966,19 @@ int main(void) } ''' - if 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) - have_optimized_crc = true - elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', - args: test_c_args + ['-march=armv8-a+crc']) - # Use ARM CRC Extension, with runtime check - cflags_crc += '-march=armv8-a+crc' - cdata.set('USE_ARMV8_CRC32C', false) - cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) - have_optimized_crc = true + if 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) + have_optimized_crc = true + elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd with -march=armv8-a+crc', + args: test_c_args + ['-march=armv8-a+crc']) + # Use ARM CRC Extension, with runtime check + cflags_crc += '-march=armv8-a+crc' + cdata.set('USE_ARMV8_CRC32C', false) + cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1) + have_optimized_crc = true + endif endif endif diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index 8b19ab160f..94d2380393 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 9e301f96f6..981718752f 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 d6bed1ce15..4882d37faf 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: 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; -- 2.38.1.windows.1 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-23 13:46 Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-23 13:46 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Tue, 19 Sept 2023 at 23:48, Michael Paquier <[email protected]> wrote: > On Tue, Sep 19, 2023 at 01:35:17PM +0100, Anthony Roberts wrote: > > Was there an explicit request for something there? I was under the > > 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 protected] > > https://www.postgresql.org/message-id/[email protected] > -- > Michael > The attached patch works with v17. I will work on getting a buildfarm animal up shortly Attachments: [application/octet-stream] windows_arm_build.patch (1.8K, ../../CADK3HH+pKM_xyg2TiWtvtP=P0N-tMtXDKW2AT+7_FLmv4u9Jrg@mail.gmail.com/3-windows_arm_build.patch) download | inline diff: diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index bb55695300..4a8793a785 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -4120,7 +4120,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/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; ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-23 21:13 Dave Cramer <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-23 21:13 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Tue, 23 Jan 2024 at 08:46, Dave Cramer <[email protected]> wrote: > > > On Tue, 19 Sept 2023 at 23:48, Michael Paquier <[email protected]> > wrote: > >> On Tue, Sep 19, 2023 at 01:35:17PM +0100, Anthony Roberts wrote: >> > Was there an explicit request for something there? I was under the >> > 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 protected] >> >> https://www.postgresql.org/message-id/[email protected] >> -- >> Michael >> > > The attached patch works with v17. I will work on getting a buildfarm > animal up shortly > > 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 > > ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-23 23:32 Michael Paquier <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2024-01-23 23:32 UTC (permalink / raw) To: Dave Cramer <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Tue, Jan 23, 2024 at 04:13:05PM -0500, Dave Cramer wrote: > On Tue, 23 Jan 2024 at 08:46, Dave Cramer <[email protected]> wrote: >> The attached patch works with v17. I will work on getting a buildfarm >> animal up shortly Thanks for doing that! > 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 ? Probably build.ninja and the contents of meson-logs/ would offer enough information? -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-24 11:45 Dave Cramer <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-24 11:45 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Tue, 23 Jan 2024 at 18:32, Michael Paquier <[email protected]> wrote: > On Tue, Jan 23, 2024 at 04:13:05PM -0500, Dave Cramer wrote: > > On Tue, 23 Jan 2024 at 08:46, Dave Cramer <[email protected]> > wrote: > >> The attached patch works with v17. I will work on getting a buildfarm > >> animal up shortly > > Thanks for doing that! > > > 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 ? > > Probably build.ninja and the contents of meson-logs/ would offer > enough information? > -- > Michael > 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 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 00:02 Michael Paquier <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 2 replies; 90+ messages in thread From: Michael Paquier @ 2024-01-25 00:02 UTC (permalink / raw) To: Dave Cramer <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote: > 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. 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 Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 13:31 Dave Cramer <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-25 13:31 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Wed, 24 Jan 2024 at 19:03, Michael Paquier <[email protected]> wrote: > On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote: > > 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. > > 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]. > 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 > checks and coverage. > Does TAP have to be explicitly added to the meson build ? Dave ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 13:45 Dave Cramer <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-25 13:45 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Thu, 25 Jan 2024 at 08:31, Dave Cramer <[email protected]> wrote: > > > On Wed, 24 Jan 2024 at 19:03, Michael Paquier <[email protected]> wrote: > >> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote: >> > 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. >> >> 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]. >> > > 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 >> checks and coverage. >> > > Does TAP have to be explicitly added to the meson build ? > > Dave > 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 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 17:30 Andrew Dunstan <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 2 replies; 90+ messages in thread From: Andrew Dunstan @ 2024-01-25 17:30 UTC (permalink / raw) To: Michael Paquier <[email protected]>; Dave Cramer <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On 2024-01-24 We 19:02, Michael Paquier wrote: > On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote: >> 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. > 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 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 -- Andrew Dunstan EDB:https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 19:07 Dave Cramer <[email protected]> parent: Andrew Dunstan <[email protected]> 1 sibling, 0 replies; 90+ messages in thread From: Dave Cramer @ 2024-01-25 19:07 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan <[email protected]> wrote: > > On 2024-01-24 We 19:02, Michael Paquier wrote: > > On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote: > > 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. > > 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 > > > > 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 > I need it to build clients. The clients need arm64 libraries to link against Dave ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 19:31 Andrew Dunstan <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andrew Dunstan @ 2024-01-25 19:31 UTC (permalink / raw) To: Dave Cramer <[email protected]>; Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> 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 > Status Line: 492 bad branch parameter > Content: > bad branch parameter fix_arm > > Web txn failed with status: 1 You can't use your own branch with the buildfarm, you need to let it set up its own branches. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 20:56 Dave Cramer <[email protected]> parent: Andrew Dunstan <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-25 20:56 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Thu, 25 Jan 2024 at 14:31, Andrew Dunstan <[email protected]> wrote: > > 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 > Status Line: 492 bad branch parameter > Content: > bad branch parameter fix_arm > > Web txn failed with status: 1 > > > > You can't use your own branch with the buildfarm, you need to let it set > up its own branches. > So I guess I have to wait until this patch is merged in ? Dave ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 21:01 Dave Cramer <[email protected]> parent: Andrew Dunstan <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-25 21:01 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan <[email protected]> wrote: > > On 2024-01-24 We 19:02, Michael Paquier wrote: > > On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote: > > 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. > > 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 > > > > 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 > 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 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 21:03 Anthony Roberts <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Anthony Roberts @ 2024-01-25 21:03 UTC (permalink / raw) To: Dave Cramer <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> Hi David, Unix "file" or "dumpbin /headers" in vcvarsall are your best bets. Thanks, Anthony On Thu, 25 Jan 2024, 21:01 Dave Cramer, <[email protected]> wrote: > > > On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan <[email protected]> wrote: > >> >> On 2024-01-24 We 19:02, Michael Paquier wrote: >> >> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote: >> >> 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. >> >> 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 >> >> >> >> 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 >> > > 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 > ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 21:14 Andrew Dunstan <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 0 replies; 90+ messages in thread From: Andrew Dunstan @ 2024-01-25 21:14 UTC (permalink / raw) To: Dave Cramer <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On 2024-01-25 Th 15:56, Dave Cramer wrote: > > > On Thu, 25 Jan 2024 at 14:31, Andrew Dunstan <[email protected]> wrote: > > > 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 >> Status Line: 492 bad branch parameter >> Content: >> bad branch parameter fix_arm >> >> Web txn failed with status: 1 > > > > You can't use your own branch with the buildfarm, you need to let > it set up its own branches. > > > So I guess I have to wait until this patch is merged in ? > > 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 -- Andrew Dunstan EDB:https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 21:17 Dave Cramer <[email protected]> parent: Anthony Roberts <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-25 21:17 UTC (permalink / raw) To: Anthony Roberts <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Thu, 25 Jan 2024 at 16:04, Anthony Roberts <[email protected]> wrote: > Hi David, > > Unix "file" or "dumpbin /headers" in vcvarsall are your best bets. > > Thanks, > Anthony > 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 > ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 21:32 Andrew Dunstan <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andrew Dunstan @ 2024-01-25 21:32 UTC (permalink / raw) To: Dave Cramer <[email protected]>; Anthony Roberts <[email protected]>; +Cc: Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On 2024-01-25 Th 16:17, Dave Cramer wrote: > > > On Thu, 25 Jan 2024 at 16:04, Anthony Roberts > <[email protected]> wrote: > > Hi David, > > Unix "file" or "dumpbin /headers" in vcvarsall are your best bets. > > Thanks, > Anthony > > > > 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 :( > 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 -- Andrew Dunstan EDB:https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-25 21:52 Dave Cramer <[email protected]> parent: Andrew Dunstan <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-25 21:52 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]> wrote: > > On 2024-01-25 Th 16:17, Dave Cramer wrote: > > > > On Thu, 25 Jan 2024 at 16:04, Anthony Roberts <[email protected]> > wrote: > >> Hi David, >> >> Unix "file" or "dumpbin /headers" in vcvarsall are your best bets. >> >> Thanks, >> Anthony >> > > > 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 :( > > > 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". > Yup, now I'm in the same state you are Dave ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-26 01:32 Michael Paquier <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Michael Paquier @ 2024-01-26 01:32 UTC (permalink / raw) To: Dave Cramer <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote: > On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]> wrote: >> On 2024-01-25 Th 16:17, Dave Cramer wrote: >> 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". > > 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 Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-26 12:36 Andrew Dunstan <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andrew Dunstan @ 2024-01-26 12:36 UTC (permalink / raw) To: Michael Paquier <[email protected]>; Dave Cramer <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On 2024-01-25 Th 20:32, Michael Paquier wrote: > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote: >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]> wrote: >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: >>> 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". >> 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 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 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-26 14:18 Dave Cramer <[email protected]> parent: Andrew Dunstan <[email protected]> 0 siblings, 2 replies; 90+ messages in thread From: Dave Cramer @ 2024-01-26 14:18 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> wrote: > > On 2024-01-25 Th 20:32, Michael Paquier wrote: > > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote: > >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]> > wrote: > >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: > >>> 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". > >> 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 > > > 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. > I've rebuilt it using x64_arm64 and with the attached (very naive patch) and I still get an x64 binary :( > > Attachments: [application/octet-stream] lock.patch (1.6K, ../../CADK3HHJgTqi7ZeKhBvegTk1=rzDYfGgEJqZN-hNMvQPAJ6R3PA@mail.gmail.com/3-lock.patch) download | inline diff: diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index aa06e49da2..61f365d0f5 100644 --- a/src/include/storage/s_lock.h +++ b/src/include/storage/s_lock.h @@ -256,8 +256,8 @@ spin_delay(void) * We use the int-width variant of the builtin because it works on more chips * than other widths. */ -#if defined(__arm__) || defined(__arm) || defined(__aarch64__) -#ifdef HAVE_GCC__SYNC_INT32_TAS +#if defined(__arm__) || defined(__arm) || defined(__aarch64__) || defined(_M_ARM64) +//#ifdef HAVE_GCC__SYNC_INT32_TAS #define HAS_TEST_AND_SET #define TAS(lock) tas(lock) @@ -277,7 +277,7 @@ tas(volatile slock_t *lock) * high-core-count ARM64 processors. It seems mostly a wash for smaller gear, * and ISB doesn't exist at all on pre-v7 ARM chips. */ -#if defined(__aarch64__) +#if defined(__aarch64__) || defined(_M_ARM64) #define SPIN_DELAY() spin_delay() @@ -288,9 +288,9 @@ spin_delay(void) " isb; \n"); } -#endif /* __aarch64__ */ -#endif /* HAVE_GCC__SYNC_INT32_TAS */ -#endif /* __arm__ || __arm || __aarch64__ */ +#endif /* __aarch64__ _M_ARM64 */ +//#endif /* HAVE_GCC__SYNC_INT32_TAS */ +#endif /* __arm__ || __arm || __aarch64__ _M_ARM64 */ /* S/390 and S/390x Linux (32- and 64-bit zSeries) */ @@ -710,6 +710,7 @@ typedef LONG slock_t; /* If using Visual C++ on Win64, inline assembly is unavailable. * Use a _mm_pause intrinsic instead of rep nop. */ +#if !defined(_M_ARM64) #if defined(_WIN64) static __forceinline void spin_delay(void) @@ -724,6 +725,7 @@ spin_delay(void) __asm rep nop; } #endif +#endif #include <intrin.h> #pragma intrinsic(_ReadWriteBarrier) ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-29 15:35 Andrew Dunstan <[email protected]> parent: Dave Cramer <[email protected]> 1 sibling, 0 replies; 90+ messages in thread From: Andrew Dunstan @ 2024-01-29 15:35 UTC (permalink / raw) To: Dave Cramer <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On 2024-01-26 Fr 09:18, Dave Cramer wrote: > > > On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> wrote: > > > On 2024-01-25 Th 20:32, Michael Paquier wrote: > > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote: > >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan > <[email protected]> wrote: > >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: > >>> 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". > >> 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 > > > 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. > > > 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 -- Andrew Dunstan EDB:https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-29 16:16 Andrew Dunstan <[email protected]> parent: Dave Cramer <[email protected]> 1 sibling, 1 reply; 90+ messages in thread From: Andrew Dunstan @ 2024-01-29 16:16 UTC (permalink / raw) To: Dave Cramer <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On 2024-01-26 Fr 09:18, Dave Cramer wrote: > > > On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> wrote: > > > On 2024-01-25 Th 20:32, Michael Paquier wrote: > > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote: > >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan > <[email protected]> wrote: > >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: > >>> 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". > >> 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 > > > 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. > > > I've rebuilt it using x64_arm64 and with the attached (very naive > 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 src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-29 16:20 Dave Cramer <[email protected]> parent: Andrew Dunstan <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-29 16:20 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> Dave Cramer www.postgres.rocks On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <[email protected]> wrote: > > On 2024-01-26 Fr 09:18, Dave Cramer wrote: > > > > On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> wrote: > >> >> On 2024-01-25 Th 20:32, Michael Paquier wrote: >> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote: >> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]> >> wrote: >> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: >> >>> 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". >> >> 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 >> >> >> 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. >> > > I've rebuilt it using x64_arm64 and with the attached (very naive 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 > > src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals > Did you add the latest lock.patch ? Dave ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-30 13:38 Andrew Dunstan <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andrew Dunstan @ 2024-01-30 13:38 UTC (permalink / raw) To: Dave Cramer <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On 2024-01-29 Mo 11:20, Dave Cramer wrote: > > Dave Cramer > www.postgres.rocks > > > On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <[email protected]> wrote: > > > On 2024-01-26 Fr 09:18, Dave Cramer wrote: >> >> >> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan >> <[email protected]> wrote: >> >> >> On 2024-01-25 Th 20:32, Michael Paquier wrote: >> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote: >> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan >> <[email protected]> wrote: >> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: >> >>> 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". >> >> 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 >> >> >> 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. >> >> >> I've rebuilt it using x64_arm64 and with the attached (very >> naive 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 > > src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals > > > Did you add the latest lock.patch ? > > 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 -- Andrew Dunstan EDB:https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-30 14:50 Dave Cramer <[email protected]> parent: Andrew Dunstan <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-30 14:50 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan <[email protected]> wrote: > > On 2024-01-29 Mo 11:20, Dave Cramer wrote: > > > Dave Cramer > www.postgres.rocks > > > On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <[email protected]> wrote: > >> >> On 2024-01-26 Fr 09:18, Dave Cramer wrote: >> >> >> >> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> wrote: >> >>> >>> On 2024-01-25 Th 20:32, Michael Paquier wrote: >>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote: >>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]> >>> wrote: >>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: >>> >>> 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". >>> >> 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 >>> >>> >>> 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. >>> >> >> I've rebuilt it using x64_arm64 and with the attached (very naive 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 >> >> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals >> > > Did you add the latest lock.patch ? > > > > > 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 Attachments: [application/octet-stream] 0001-fix-build-for-arm.patch (2.2K, ../../CADK3HHK1e2CEa5fYReZHt-iKcZtEMTZUnNxXoeTCnzyCfcG9Ew@mail.gmail.com/3-0001-fix-build-for-arm.patch) download | inline diff: From 19284a00142a1d3854d89b60e641e2048cbf1bb1 Mon Sep 17 00:00:00 2001 From: davecramer <[email protected]> Date: Tue, 23 Jan 2024 13:29:48 -0500 Subject: [PATCH 1/2] fix build for arm --- doc/src/sgml/installation.sgml | 2 +- src/tools/msvc_gendef.pl | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index e73902b3f8..686a342150 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/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; -- 2.43.0.windows.1 [application/octet-stream] 0002-naive-patch-to-fix-locking-for-arm64.patch (1.9K, ../../CADK3HHK1e2CEa5fYReZHt-iKcZtEMTZUnNxXoeTCnzyCfcG9Ew@mail.gmail.com/4-0002-naive-patch-to-fix-locking-for-arm64.patch) download | inline diff: From 0661774349f2a96c7aa4aaac328aca4118857f4a Mon Sep 17 00:00:00 2001 From: davecramer <[email protected]> Date: Tue, 30 Jan 2024 09:47:25 -0500 Subject: [PATCH 2/2] naive patch to fix locking for arm64 --- src/include/storage/s_lock.h | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index aa06e49da2..61f365d0f5 100644 --- a/src/include/storage/s_lock.h +++ b/src/include/storage/s_lock.h @@ -256,8 +256,8 @@ spin_delay(void) * We use the int-width variant of the builtin because it works on more chips * than other widths. */ -#if defined(__arm__) || defined(__arm) || defined(__aarch64__) -#ifdef HAVE_GCC__SYNC_INT32_TAS +#if defined(__arm__) || defined(__arm) || defined(__aarch64__) || defined(_M_ARM64) +//#ifdef HAVE_GCC__SYNC_INT32_TAS #define HAS_TEST_AND_SET #define TAS(lock) tas(lock) @@ -277,7 +277,7 @@ tas(volatile slock_t *lock) * high-core-count ARM64 processors. It seems mostly a wash for smaller gear, * and ISB doesn't exist at all on pre-v7 ARM chips. */ -#if defined(__aarch64__) +#if defined(__aarch64__) || defined(_M_ARM64) #define SPIN_DELAY() spin_delay() @@ -288,9 +288,9 @@ spin_delay(void) " isb; \n"); } -#endif /* __aarch64__ */ -#endif /* HAVE_GCC__SYNC_INT32_TAS */ -#endif /* __arm__ || __arm || __aarch64__ */ +#endif /* __aarch64__ _M_ARM64 */ +//#endif /* HAVE_GCC__SYNC_INT32_TAS */ +#endif /* __arm__ || __arm || __aarch64__ _M_ARM64 */ /* S/390 and S/390x Linux (32- and 64-bit zSeries) */ @@ -710,6 +710,7 @@ typedef LONG slock_t; /* If using Visual C++ on Win64, inline assembly is unavailable. * Use a _mm_pause intrinsic instead of rep nop. */ +#if !defined(_M_ARM64) #if defined(_WIN64) static __forceinline void spin_delay(void) @@ -724,6 +725,7 @@ spin_delay(void) __asm rep nop; } #endif +#endif #include <intrin.h> #pragma intrinsic(_ReadWriteBarrier) -- 2.43.0.windows.1 ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-30 21:56 Andrew Dunstan <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andrew Dunstan @ 2024-01-30 21:56 UTC (permalink / raw) To: Dave Cramer <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]> On 2024-01-30 Tu 09:50, Dave Cramer wrote: > > > On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan <[email protected]> wrote: > > > On 2024-01-29 Mo 11:20, Dave Cramer wrote: >> >> Dave Cramer >> www.postgres.rocks <http://www.postgres.rocks; >> >> >> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan >> <[email protected]> wrote: >> >> >> On 2024-01-26 Fr 09:18, Dave Cramer wrote: >>> >>> >>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan >>> <[email protected]> wrote: >>> >>> >>> On 2024-01-25 Th 20:32, Michael Paquier wrote: >>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer >>> wrote: >>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan >>> <[email protected]> wrote: >>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: >>> >>> 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". >>> >> 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 >>> >>> >>> 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. >>> >>> >>> I've rebuilt it using x64_arm64 and with the attached (very >>> naive 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 >> >> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved >> externals >> >> >> Did you add the latest lock.patch ? >> >> > > > 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. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-30 22:54 Dave Cramer <[email protected]> parent: Andrew Dunstan <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Dave Cramer @ 2024-01-30 22:54 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: Andres Freund <[email protected]>; Anthony Roberts <[email protected]>; Daniel Gustafsson <[email protected]>; Lina Iyer <[email protected]>; Michael Paquier <[email protected]>; Mike Holmes <[email protected]>; Peter Eisentraut <[email protected]>; PostgreSQL Hackers <[email protected]>; Thomas Munro <[email protected]>; Tom Lane <[email protected]> On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan <[email protected]> wrote: > > On 2024-01-30 Tu 09:50, Dave Cramer wrote: > > > > On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan <[email protected]> wrote: > >> >> On 2024-01-29 Mo 11:20, Dave Cramer wrote: >> >> >> Dave Cramer >> www.postgres.rocks >> >> >> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <[email protected]> wrote: >> >>> >>> On 2024-01-26 Fr 09:18, Dave Cramer wrote: >>> >>> >>> >>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> >>> wrote: >>> >>>> >>>> On 2024-01-25 Th 20:32, Michael Paquier wrote: >>>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote: >>>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]> >>>> wrote: >>>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: >>>> >>> 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". >>>> >> 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 >>>> >>>> >>>> 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. >>>> >>> >>> I've rebuilt it using x64_arm64 and with the attached (very naive >>> 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 >>> >>> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals >>> >> >> Did you add the latest lock.patch ? >> >> >> >> >> 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. > > Okay I will look when I get home in a week Dave > > cheers > > > andrew > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com > > ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-31 15:20 Andrew Dunstan <[email protected]> parent: Dave Cramer <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Andrew Dunstan @ 2024-01-31 15:20 UTC (permalink / raw) To: Dave Cramer <[email protected]>; +Cc: Andres Freund <[email protected]>; Anthony Roberts <[email protected]>; Daniel Gustafsson <[email protected]>; Lina Iyer <[email protected]>; Michael Paquier <[email protected]>; Mike Holmes <[email protected]>; Peter Eisentraut <[email protected]>; PostgreSQL Hackers <[email protected]>; Thomas Munro <[email protected]>; Tom Lane <[email protected]> On 2024-01-30 Tu 17:54, Dave Cramer wrote: > > > > On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan <[email protected]> > wrote: > > > On 2024-01-30 Tu 09:50, Dave Cramer wrote: >> >> >> On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan >> <[email protected]> wrote: >> >> >> On 2024-01-29 Mo 11:20, Dave Cramer wrote: >>> >>> Dave Cramer >>> www.postgres.rocks <http://www.postgres.rocks; >>> >>> >>> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan >>> <[email protected]> wrote: >>> >>> >>> On 2024-01-26 Fr 09:18, Dave Cramer wrote: >>>> >>>> >>>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan >>>> <[email protected]> wrote: >>>> >>>> >>>> On 2024-01-25 Th 20:32, Michael Paquier wrote: >>>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave >>>> Cramer wrote: >>>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan >>>> <[email protected]> wrote: >>>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: >>>> >>> 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". >>>> >> 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 >>>> >>>> >>>> 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. >>>> >>>> >>>> I've rebuilt it using x64_arm64 and with the attached >>>> (very naive 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 >>> >>> src\backend\postgres.exe : fatal error LNK1120: 1 >>> unresolved externals >>> >>> >>> Did you add the latest lock.patch ? >>> >>> >> >> >> 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. > > > Okay I will look when I get home in a week I made some progress. The attached is mostly taken from <https://postgr.es/m/[email protected]; 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 Attachments: [text/x-patch] arm64.patch (3.9K, ../../[email protected]/3-arm64.patch) download | inline diff: 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; ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-31 15:34 Peter Eisentraut <[email protected]> parent: Andrew Dunstan <[email protected]> 0 siblings, 1 reply; 90+ messages in thread From: Peter Eisentraut @ 2024-01-31 15:34 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; Dave Cramer <[email protected]>; +Cc: Andres Freund <[email protected]>; Anthony Roberts <[email protected]>; Daniel Gustafsson <[email protected]>; Lina Iyer <[email protected]>; Michael Paquier <[email protected]>; Mike Holmes <[email protected]>; PostgreSQL Hackers <[email protected]>; Thomas Munro <[email protected]>; Tom Lane <[email protected]> On 31.01.24 16:20, Andrew Dunstan 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. 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? ^ permalink raw reply [nested|flat] 90+ messages in thread
* Re: [PATCH] Add native windows on arm64 support @ 2024-01-31 15:41 Andrew Dunstan <[email protected]> parent: Peter Eisentraut <[email protected]> 0 siblings, 0 replies; 90+ messages in thread From: Andrew Dunstan @ 2024-01-31 15:41 UTC (permalink / raw) To: Peter Eisentraut <[email protected]>; Dave Cramer <[email protected]>; +Cc: Andres Freund <[email protected]>; Anthony Roberts <[email protected]>; Daniel Gustafsson <[email protected]>; Lina Iyer <[email protected]>; Michael Paquier <[email protected]>; Mike Holmes <[email protected]>; PostgreSQL Hackers <[email protected]>; Thomas Munro <[email protected]>; Tom Lane <[email protected]> On 2024-01-31 We 10:34, Peter Eisentraut wrote: > On 31.01.24 16:20, Andrew Dunstan 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. > > 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? x86? That is in fact the default setting for VS even on ARM64. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 90+ messages in thread
end of thread, other threads:[~2024-01-31 15:41 UTC | newest] Thread overview: 90+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2022-03-23 03:30 Re: [PATCH] Add native windows on arm64 support Thomas Munro <[email protected]> 2022-03-24 01:15 ` Andres Freund <[email protected]> 2022-03-24 22:38 ` Thomas Munro <[email protected]> 2022-04-07 06:36 ` Michael Paquier <[email protected]> 2022-04-20 00:28 ` Michael Paquier <[email protected]> 2022-04-21 04:07 ` Michael Paquier <[email protected]> 2022-04-25 01:17 ` Michael Paquier <[email protected]> 2022-05-09 11:44 ` Niyas Sait <[email protected]> 2022-05-10 01:01 ` Michael Paquier <[email protected]> 2022-07-14 08:36 ` Niyas Sait <[email protected]> 2022-08-26 01:29 ` Andres Freund <[email protected]> 2022-08-26 02:09 ` Michael Paquier <[email protected]> 2022-08-26 03:29 ` Andres Freund <[email protected]> 2022-08-27 02:33 ` Michael Paquier <[email protected]> 2022-08-27 03:02 ` Tom Lane <[email protected]> 2022-08-27 19:27 ` Andres Freund <[email protected]> 2022-08-28 07:23 ` Michael Paquier <[email protected]> 2022-08-28 14:09 ` Tom Lane <[email protected]> 2022-08-28 15:41 ` Andres Freund <[email protected]> 2022-08-28 15:51 ` Tom Lane <[email protected]> 2022-08-29 01:12 ` Michael Paquier <[email protected]> 2022-08-29 23:48 ` Michael Paquier <[email protected]> 2022-08-29 23:58 ` Tom Lane <[email protected]> 2022-08-30 00:33 ` Andres Freund <[email protected]> 2022-08-30 01:35 ` Michael Paquier <[email protected]> 2022-08-30 02:00 ` Tom Lane <[email protected]> 2022-08-30 23:36 ` Michael Paquier <[email protected]> 2022-08-31 00:07 ` Tom Lane <[email protected]> 2022-08-31 00:16 ` Michael Paquier <[email protected]> 2022-08-31 00:15 ` Michael Paquier <[email protected]> 2022-08-31 00:28 ` Tom Lane <[email protected]> 2022-08-31 06:09 ` Michael Paquier <[email protected]> 2022-08-31 17:33 ` Tom Lane <[email protected]> 2022-09-01 00:32 ` Michael Paquier <[email protected]> 2022-09-01 02:22 ` Tom Lane <[email protected]> 2022-09-01 04:41 ` Michael Paquier <[email protected]> 2022-11-03 08:38 ` Ian Lawrence Barwick <[email protected]> 2022-11-03 11:06 ` Niyas Sait <[email protected]> 2022-11-03 11:43 ` Michael Paquier <[email protected]> 2022-11-05 18:31 ` Andres Freund <[email protected]> 2022-11-07 06:58 ` Michael Paquier <[email protected]> 2022-12-01 07:42 ` Michael Paquier <[email protected]> 2022-12-01 17:20 ` Niyas Sait <[email protected]> 2022-12-01 17:53 ` Niyas Sait <[email protected]> 2022-12-02 05:02 ` Michael Paquier <[email protected]> 2022-12-02 09:37 ` Niyas Sait <[email protected]> 2022-12-02 11:09 ` Niyas Sait <[email protected]> 2022-12-05 05:12 ` Michael Paquier <[email protected]> 2022-12-05 08:54 ` Niyas Sait <[email protected]> 2022-12-05 18:14 ` Andres Freund <[email protected]> 2022-12-05 23:31 ` Michael Paquier <[email protected]> 2022-12-05 23:48 ` Andres Freund <[email protected]> 2022-12-06 00:16 ` Michael Paquier <[email protected]> 2022-12-12 13:38 ` Niyas Sait <[email protected]> 2022-12-12 23:56 ` Michael Paquier <[email protected]> 2022-12-16 10:52 ` Niyas Sait <[email protected]> 2022-12-02 05:41 ` John Naylor <[email protected]> 2022-12-02 09:50 ` Niyas Sait <[email protected]> 2022-12-01 17:17 ` Niyas Sait <[email protected]> 2022-08-30 00:09 ` Andres Freund <[email protected]> 2024-01-23 13:46 Re: [PATCH] Add native windows on arm64 support Dave Cramer <[email protected]> 2024-01-23 21:13 ` Dave Cramer <[email protected]> 2024-01-23 23:32 ` Michael Paquier <[email protected]> 2024-01-24 11:45 ` Dave Cramer <[email protected]> 2024-01-25 00:02 ` Michael Paquier <[email protected]> 2024-01-25 13:31 ` Dave Cramer <[email protected]> 2024-01-25 13:45 ` Dave Cramer <[email protected]> 2024-01-25 19:31 ` Andrew Dunstan <[email protected]> 2024-01-25 20:56 ` Dave Cramer <[email protected]> 2024-01-25 21:14 ` Andrew Dunstan <[email protected]> 2024-01-25 17:30 ` Andrew Dunstan <[email protected]> 2024-01-25 19:07 ` Dave Cramer <[email protected]> 2024-01-25 21:01 ` Dave Cramer <[email protected]> 2024-01-25 21:03 ` Anthony Roberts <[email protected]> 2024-01-25 21:17 ` Dave Cramer <[email protected]> 2024-01-25 21:32 ` Andrew Dunstan <[email protected]> 2024-01-25 21:52 ` Dave Cramer <[email protected]> 2024-01-26 01:32 ` Michael Paquier <[email protected]> 2024-01-26 12:36 ` Andrew Dunstan <[email protected]> 2024-01-26 14:18 ` Dave Cramer <[email protected]> 2024-01-29 15:35 ` Andrew Dunstan <[email protected]> 2024-01-29 16:16 ` Andrew Dunstan <[email protected]> 2024-01-29 16:20 ` Dave Cramer <[email protected]> 2024-01-30 13:38 ` Andrew Dunstan <[email protected]> 2024-01-30 14:50 ` Dave Cramer <[email protected]> 2024-01-30 21:56 ` Andrew Dunstan <[email protected]> 2024-01-30 22:54 ` Dave Cramer <[email protected]> 2024-01-31 15:20 ` Andrew Dunstan <[email protected]> 2024-01-31 15:34 ` Peter Eisentraut <[email protected]> 2024-01-31 15:41 ` Andrew Dunstan <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox