Re: [PATCH] Add native windows on arm64 support

[Thomas Munro]

On Wed, Oct 9, 2024 at 12:58 PM Dave Cramer  wrote:
> ..\src\include/port/atomics/arch-x86.h:39: warning: "pg_memory_barrier_impl" 
> redefined

It shouldn't be including that.  Does the patch here help?

https://www.postgresql.org/message-id/CA%2BhUKG%2BOu%2BC%2BpXioo_W1gKcwRCEN1WNrLBBPSMJyxjgc%2B1JEJA%40mail.gmail.com

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Sun, 29 Sept 2024 at 06:31, Dave Cramer 
wrote:

>
> On Sat, 28 Sept 2024 at 20:03, Thomas Munro 
> wrote:
>
>> On Tue, Feb 13, 2024 at 10:01 AM Dave Cramer 
>> wrote:
>> > > postgres.exe!dsa_free(dsa_area * area, unsigned __int64 dp) Line 869 C
>> >   postgres.exe!resize(dshash_table * hash_table, unsigned __int64
>> new_size_log2) Line 879 C
>> >   postgres.exe!dshash_find_or_insert(dshash_table * hash_table, const
>> void * key, bool * found) Line 480 C
>> >   postgres.exe!pgstat_get_entry_ref(PgStat_Kind kind, unsigned int
>> dboid, unsigned int objoid, bool create, bool * created_entry) Line 455 C
>>
>> Hmm, we can see that the spinlock stuff is too weak (assumes TSO), but
>> there aren't any spinlocks near that code so I think something else is
>> wrong.  What does pg_read_barrier() compile to?  I mention that
>> because it's used near there in a somewhat complicated way.  But I'm a
>> bit confused because by reading through the code it looks like it
>> should be too strong, not too weak.  I think it should fall back to
>> pg_memory_barrier_impl() for lack of pg_read_barrier_impl(), which
>> should produce MemoryBarrier() and I guess DMB SY (ARM instruction for
>> full system data memory barrier).  So maybe some other pg_atomic_XXX
>> operations are falling back to code that doesn't work.
>>
>> Just for experimentation, you could see what happens if you redirect
>> all that stuff to C11's .  Here's a quick-and-dirty patch
>> for that, which works on my ARM Mac, but I have no idea if it'll work
>> on MSVC (our CI uses MSVC 2019; they only added  in MSVC
>> 2022, but that's the same edition that added ARM so you must have it).
>> It's not a very finely tuned patch (for example I think several calls
>> should use the _explicit() variants and be weaker, but they err on the
>> side of being too strong, so the code they generate is probably not as
>> fast as it could be; I lost interested when the general idea was
>> rejected for now, but it might help learn something about the MSVC+ARM
>> situation).
>>
>> Combined with the patch that redirects spinlocks to atomics[1], there
>> would be no 'hand rolled' code relating to memory order or atomics,
>> just standard modern C.  There are obviously other architecture tests
>> here and there, and some of them will be wrong (some of them are wrong
>> already for MSVC on x86), and that might be fixed by project
>> standardisation[2].
>>
>> [1]
>> https://www.postgresql.org/message-id/CA%2BhUKGJ%2BoA%2B62iUZ-EQb5R2cAOW3Y942ZoOtzOD%3D1sQ05iNg6Q%40mail.gmail.com
>> [2]
>> https://www.postgresql.org/message-id/CA%2BhUKG%2BOu%2BC%2BpXioo_W1gKcwRCEN1WNrLBBPSMJyxjgc%2B1JEJA%40mail.gmail.com
>
>
>

Getting the following errors building it

FAILED: src/backend/nodes/nodefuncs.a.p/equalfuncs.c.obj
"ccache" "gcc" "-Isrc\backend\nodes\nodefuncs.a.p" "-Isrc\include\nodes"
"-I..\src\include\nodes" "-Isrc\include" "-I..\src\include"
"-I..\src\include\port\win32" "-IC:/Strawberry/c/include"
"-fdiagnostics-color=always" "-D_FILE_OFFSET_BITS=64" "-Wall"
"-Winvalid-pch" "-O2" "-g" "-fno-strict-aliasing" "-fwrapv"
"-fexcess-precision=standard" "-Wmissing-prototypes" "-Wpointer-arith"
"-Werror=vla" "-Wendif-labels" "-Wmissing-format-attribute"
"-Wimplicit-fallthrough=3" "-Wcast-function-type"
"-Wshadow=compatible-local" "-Wformat-security"
"-Wdeclaration-after-statement" "-Wno-format-truncation"
"-Wno-stringop-truncation" "-pthread" "-DBUILDING_DLL" -MD -MQ
src/backend/nodes/nodefuncs.a.p/equalfuncs.c.obj -MF
"src\backend\nodes\nodefuncs.a.p\equalfuncs.c.obj.d" -o
src/backend/nodes/nodefuncs.a.p/equalfuncs.c.obj "-c"
../src/backend/nodes/equalfuncs.c
In file included from ..\src\include/port/atomics.h:180,
 from ..\src\include/utils/dsa.h:17,
 from ..\src\include/nodes/tidbitmap.h:26,
 from ..\src\include/access/genam.h:19,
 from ..\src\include/access/amapi.h:15,
 from src\include\nodes/equalfuncs.funcs.c:18,
 from ../src/backend/nodes/equalfuncs.c:88:
..\src\include/port/atomics/arch-x86.h:39: warning:
"pg_memory_barrier_impl" redefined
   39 | #define pg_memory_barrier_impl()\
  |
..\src\include/port/atomics.h:60: note: this is the location of the
previous definition
   60 | #define pg_memory_barrier_impl()
atomic_thread_fence(memory_order_seq_cst)
  |
..\src\include/port/atomics/arch-x86.h:44: warning: "pg_read_barrier_impl"
redefined
   44 | #define pg_read_barrier_impl()  pg_compiler_barrier_impl()
  |
..\src\include/port/atomics.h:61: note: this is the location of the
previous definition
   61 | #define pg_read_barrier_impl()
atomic_thread_fence(memory_order_acquire)
  |
..\src\include/port/atomics/arch-x86.h:45: warning: "pg_write_barrier_impl"
redefined
   45 | #define pg_write_barrier_impl() pg_compiler_barrier_impl()
  |
..\src\include/port/atomics.h:62: note: this is the location of the
previous definition
   62 | #define pg_w

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Sat, 28 Sept 2024 at 20:03, Thomas Munro  wrote:

> On Tue, Feb 13, 2024 at 10:01 AM Dave Cramer 
> wrote:
> > > postgres.exe!dsa_free(dsa_area * area, unsigned __int64 dp) Line 869 C
> >   postgres.exe!resize(dshash_table * hash_table, unsigned __int64
> new_size_log2) Line 879 C
> >   postgres.exe!dshash_find_or_insert(dshash_table * hash_table, const
> void * key, bool * found) Line 480 C
> >   postgres.exe!pgstat_get_entry_ref(PgStat_Kind kind, unsigned int
> dboid, unsigned int objoid, bool create, bool * created_entry) Line 455 C
>
> Hmm, we can see that the spinlock stuff is too weak (assumes TSO), but
> there aren't any spinlocks near that code so I think something else is
> wrong.  What does pg_read_barrier() compile to?  I mention that
> because it's used near there in a somewhat complicated way.  But I'm a
> bit confused because by reading through the code it looks like it
> should be too strong, not too weak.  I think it should fall back to
> pg_memory_barrier_impl() for lack of pg_read_barrier_impl(), which
> should produce MemoryBarrier() and I guess DMB SY (ARM instruction for
> full system data memory barrier).  So maybe some other pg_atomic_XXX
> operations are falling back to code that doesn't work.
>
> Just for experimentation, you could see what happens if you redirect
> all that stuff to C11's .  Here's a quick-and-dirty patch
> for that, which works on my ARM Mac, but I have no idea if it'll work
> on MSVC (our CI uses MSVC 2019; they only added  in MSVC
> 2022, but that's the same edition that added ARM so you must have it).
> It's not a very finely tuned patch (for example I think several calls
> should use the _explicit() variants and be weaker, but they err on the
> side of being too strong, so the code they generate is probably not as
> fast as it could be; I lost interested when the general idea was
> rejected for now, but it might help learn something about the MSVC+ARM
> situation).
>
> Combined with the patch that redirects spinlocks to atomics[1], there
> would be no 'hand rolled' code relating to memory order or atomics,
> just standard modern C.  There are obviously other architecture tests
> here and there, and some of them will be wrong (some of them are wrong
> already for MSVC on x86), and that might be fixed by project
> standardisation[2].
>
> [1]
> https://www.postgresql.org/message-id/CA%2BhUKGJ%2BoA%2B62iUZ-EQb5R2cAOW3Y942ZoOtzOD%3D1sQ05iNg6Q%40mail.gmail.com
> [2]
> https://www.postgresql.org/message-id/CA%2BhUKG%2BOu%2BC%2BpXioo_W1gKcwRCEN1WNrLBBPSMJyxjgc%2B1JEJA%40mail.gmail.com



Thomas,

Thanks, I will be able to try this when I get back from NY. So Thurs or so.

Dave

Re: [PATCH] Add native windows on arm64 support

[Thomas Munro]

On Tue, Feb 13, 2024 at 10:01 AM Dave Cramer  wrote:
> > postgres.exe!dsa_free(dsa_area * area, unsigned __int64 dp) Line 869 C
>   postgres.exe!resize(dshash_table * hash_table, unsigned __int64 
> new_size_log2) Line 879 C
>   postgres.exe!dshash_find_or_insert(dshash_table * hash_table, const void * 
> key, bool * found) Line 480 C
>   postgres.exe!pgstat_get_entry_ref(PgStat_Kind kind, unsigned int dboid, 
> unsigned int objoid, bool create, bool * created_entry) Line 455 C

Hmm, we can see that the spinlock stuff is too weak (assumes TSO), but
there aren't any spinlocks near that code so I think something else is
wrong.  What does pg_read_barrier() compile to?  I mention that
because it's used near there in a somewhat complicated way.  But I'm a
bit confused because by reading through the code it looks like it
should be too strong, not too weak.  I think it should fall back to
pg_memory_barrier_impl() for lack of pg_read_barrier_impl(), which
should produce MemoryBarrier() and I guess DMB SY (ARM instruction for
full system data memory barrier).  So maybe some other pg_atomic_XXX
operations are falling back to code that doesn't work.

Just for experimentation, you could see what happens if you redirect
all that stuff to C11's .  Here's a quick-and-dirty patch
for that, which works on my ARM Mac, but I have no idea if it'll work
on MSVC (our CI uses MSVC 2019; they only added  in MSVC
2022, but that's the same edition that added ARM so you must have it).
It's not a very finely tuned patch (for example I think several calls
should use the _explicit() variants and be weaker, but they err on the
side of being too strong, so the code they generate is probably not as
fast as it could be; I lost interested when the general idea was
rejected for now, but it might help learn something about the MSVC+ARM
situation).

Combined with the patch that redirects spinlocks to atomics[1], there
would be no 'hand rolled' code relating to memory order or atomics,
just standard modern C.  There are obviously other architecture tests
here and there, and some of them will be wrong (some of them are wrong
already for MSVC on x86), and that might be fixed by project
standardisation[2].

[1] 
https://www.postgresql.org/message-id/CA%2BhUKGJ%2BoA%2B62iUZ-EQb5R2cAOW3Y942ZoOtzOD%3D1sQ05iNg6Q%40mail.gmail.com
[2] 
https://www.postgresql.org/message-id/CA%2BhUKG%2BOu%2BC%2BpXioo_W1gKcwRCEN1WNrLBBPSMJyxjgc%2B1JEJA%40mail.gmail.com


0001-Optionally-do-port-atomics.h-with-stdatomic.h.patch
Description: Binary data

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-09-24 Tu 2:31 PM, Dave Cramer wrote:



On Tue, 13 Feb 2024 at 16:28, Dave Cramer  
wrote:





On Tue, 13 Feb 2024 at 12:52, Andres Freund 
wrote:

Hi,

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



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


> I did try using atomic_thread_fence as per atomic_thread_fence -
> cppreference.com 
> 

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

#defineS_UNLOCK(lock) \
do{ MemoryBarrier(); (*(lock)) =0; } while(0)
#endif
Has no effect.

I have no idea if that is what you meant that I should do ?

Dave



Revisiting this:

Andrew, can you explain the difference between ninja test (which 
passes) and what the build farm does. The buildfarm crashes.



The buildfarm client performs these steps:


   meson test -C $pgsql --no-rebuild --suite setup
   meson test -t $meson_test_timeout $jflag -C $pgsql --logbase checklog 
--print-errorlogs --no-rebuild --suite regress --test-args=--no-locale
   meson test -t $meson_test_timeout $jflag -C $pgsql --print-errorlogs 
--no-rebuild --logbase checkworld --no-suite setup --no-suite regress
   foreach tested locale: meson test -t $meson_test_timeout $jflag -v -C $pgsql 
--no-rebuild --print-errorlogs --setup running --suite regress-running 
--logbase regress-installcheck-$locale


$pgsql is the build root, $jflag is setting the number of jobs


IOW, we do test suite setup, run the core regression tests, run all the 
remaining non-install tests, then run the install tests for each locale.


We don't call ninja directly, but I don't see why that should make a 
difference.



cheers


andrew


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

Re: [PATCH] Add native windows on arm64 support

[Andres Freund]

On 2024-09-24 16:01:30 -0400, Dave Cramer wrote:
> I have a dmp file with a stack trace if anyone is interested

/me raises his hand

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 24 Sept 2024 at 14:31, Dave Cramer 
wrote:

>
>
> On Tue, 13 Feb 2024 at 16:28, Dave Cramer 
> wrote:
>
>>
>>
>>
>> On Tue, 13 Feb 2024 at 12:52, Andres Freund  wrote:
>>
>>> Hi,
>>>
>>> On 2024-02-13 12:49:33 -0500, Dave Cramer wrote:
>>> > > I think I might have been on to something - if my human emulation of
>>> a
>>> > > preprocessor isn't wrong, we'd end up with
>>> > >
>>> > > #define S_UNLOCK(lock)  \
>>> > > do { _ReadWriteBarrier(); (*(lock)) = 0; } while (0)
>>> > >
>>> > > on msvc + arm. And that's entirely insufficient -
>>> _ReadWriteBarrier() just
>>> > > limits *compiler* level reordering, not CPU level reordering.  I
>>> think it's
>>> > > even insufficient on x86[-64], but it's definitely insufficient on
>>> arm.
>>> > >
>>> > In fact ReadWriteBarrier has been deprecated _ReadWriteBarrier |
>>> Microsoft
>>> > Learn
>>> > <
>>> https://learn.microsoft.com/en-us/cpp/intrinsics/readwritebarrier?view=msvc-170
>>> >
>>>
>>> I'd just ignore that, that's just pushing towards more modern stuff
>>> that's
>>> more applicable to C++ than C.
>>>
>>>
>>> > I did try using atomic_thread_fence as per atomic_thread_fence -
>>> > cppreference.com
>>> > 
>>>
>>> The semantics of atomic_thread_fence are, uh, very odd.  I'd just use
>>> MemoryBarrier().
>>>
>>> #define S_UNLOCK(lock)  \
>> do { MemoryBarrier(); (*(lock)) = 0; } while (0)
>>
>> #endif
>>
>> Has no effect.
>>
>> I have no idea if that is what you meant that I should do ?
>>
>> Dave
>>
>
>
> Revisiting this:
>
> Andrew, can you explain the difference between ninja test (which passes)
> and what the build farm does. The buildfarm crashes.
>

I have a dmp file with a stack trace if anyone is interested

Dave

>
> Dave
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 13 Feb 2024 at 16:28, Dave Cramer  wrote:

>
>
>
> On Tue, 13 Feb 2024 at 12:52, Andres Freund  wrote:
>
>> Hi,
>>
>> On 2024-02-13 12:49:33 -0500, Dave Cramer wrote:
>> > > I think I might have been on to something - if my human emulation of a
>> > > preprocessor isn't wrong, we'd end up with
>> > >
>> > > #define S_UNLOCK(lock)  \
>> > > do { _ReadWriteBarrier(); (*(lock)) = 0; } while (0)
>> > >
>> > > on msvc + arm. And that's entirely insufficient - _ReadWriteBarrier()
>> just
>> > > limits *compiler* level reordering, not CPU level reordering.  I
>> think it's
>> > > even insufficient on x86[-64], but it's definitely insufficient on
>> arm.
>> > >
>> > In fact ReadWriteBarrier has been deprecated _ReadWriteBarrier |
>> Microsoft
>> > Learn
>> > <
>> https://learn.microsoft.com/en-us/cpp/intrinsics/readwritebarrier?view=msvc-170
>> >
>>
>> I'd just ignore that, that's just pushing towards more modern stuff that's
>> more applicable to C++ than C.
>>
>>
>> > I did try using atomic_thread_fence as per atomic_thread_fence -
>> > cppreference.com
>> > 
>>
>> The semantics of atomic_thread_fence are, uh, very odd.  I'd just use
>> MemoryBarrier().
>>
>> #define S_UNLOCK(lock)  \
> do { MemoryBarrier(); (*(lock)) = 0; } while (0)
>
> #endif
>
> Has no effect.
>
> I have no idea if that is what you meant that I should do ?
>
> Dave
>


Revisiting this:

Andrew, can you explain the difference between ninja test (which passes)
and what the build farm does. The buildfarm crashes.

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 13 Feb 2024 at 12:52, Andres Freund  wrote:

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

#endif

Has no effect.

I have no idea if that is what you meant that I should do ?

Dave

Re: [PATCH] Add native windows on arm64 support

[Andres Freund]

Hi,

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

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


> I did try using atomic_thread_fence as per atomic_thread_fence -
> cppreference.com
> 

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

Greetings,

Andres Freund

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Mon, 12 Feb 2024 at 16:19, Andres Freund  wrote:

> Hi,
>
> On 2024-02-12 12:50:12 -0800, Andres Freund wrote:
> > On 2024-02-12 13:28:40 -0500, Andrew Dunstan wrote:
> > I wonder if this indicates that we are either missing memory barriers
> > somewhere or that the memory barriers we end up with on msvc + arm aren't
> > correct?  Either could explain why the problem doesn't occur when
> building
> > with optimizations.
>
> I think I might have been on to something - if my human emulation of a
> preprocessor isn't wrong, we'd end up with
>
> #define S_UNLOCK(lock)  \
> do { _ReadWriteBarrier(); (*(lock)) = 0; } while (0)
>
> on msvc + arm. And that's entirely insufficient - _ReadWriteBarrier() just
> limits *compiler* level reordering, not CPU level reordering.  I think it's
> even insufficient on x86[-64], but it's definitely insufficient on arm.
>
In fact ReadWriteBarrier has been deprecated _ReadWriteBarrier | Microsoft
Learn


I did try using atomic_thread_fence as per atomic_thread_fence -
cppreference.com



However for some reason including #include 
causes a bunch of compiler errors.

c:\Program Files\Microsoft Visual
Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(36):
error C2061: syntax error: identifier 'atomic_bool'

Dave

Re: [PATCH] Add native windows on arm64 support

[Thomas Munro]

On Sat, Feb 10, 2024 at 8:36 AM Andres Freund  wrote:
> Also, yikes, that's an ugly way of doing hardware detection. Jumping out of a
> signal handler into normal code. Brrr.

Maybe it's a little baroque but what's actually wrong with it?
OpenSSL does something similar during initialisation as a fallback
(see armcap.c), and I borrowed that particular idea because I didn't
want the rat's nest of unportable strategies required to detect the
feature otherwise.  As people who ran OpenSSL-linked stuff under gdb
on 32 bit ARM discover (on e.g. early 32 bit RPis and early iOS etc
systems the instruction was missing, and the signal dropped you into
the debugger, so there are lots of reports of that if you google this
topic).  FWIW psql also long-jumps out of signal handlers, arguably
more questionably because it's an async signal and the program counter
may be inside readline...

As for Windows, let's see... SIGILL doesn't even work (the identifier
is defined for compatibility, but illegal instruction exception is not
connected up to it), not to mention that in the backend we redirect
sigaction() to our own fake co-operative signal system so this
technique wouldn't work even if SIGILL did.  But I would be surprised
if anyone actually has a platform that can run Windows that doesn't
have this instruction (if they did I think we'd see a crash with
untrapped illegal instruction exception 0xC01D, let me put that
here to help google to find this message if it ever happens...).
CRC32C is required by ARMv8.1[1], and was optional but AFAIK present
in general purpose ARMv8.0 cores including lowly RPis.  In other words
anything < 8 years old[2] has it certainly, and older stuff probably
does too if it is a 64 bit server/PC/laptop/RPi?  If you look for
reports of systems without it they seem to be pre-ARMv8, or early
phones/tablets (?)?

It looks like Windows 11 requires ARMv8.1[3] ("the Windows kernel
dropped ARMv8.0 support shortly after builds 22621 [= 2022], now
requiring and enforcing a minimum of ARMv8.1 and thus the new atomics
instructions", that atomic/lock stuff being a pretty solid reason to
want to do so as discussed on this list before...).  What if we just
assumed that the same must be effectively true in practice for Windows
10 until we hear otherwise?  If a reasonable non-hypothetical system
shows up that rejects this instruction in the short time before we
disclaim support for 10 (whose EOL is next year?), we can decide
whether to just turn off the CRC32 fast path for that OS version, or
figure out the runtime feature-probe patch.  Clearly we need to
minimise Windows magic in this project due to lack of hackers, so
writing code proactively for imaginary users seems like a bad plan...

[1] 
https://developer.arm.com/documentation/ddi0597/2023-12/Base-Instructions/CRC32C--CRC32C-
[2] https://en.wikipedia.org/wiki/Comparison_of_ARM_processors#ARMv8-A
[3] http://www.emulators.com/docs/abc_history_of_woa.htm

Re: [PATCH] Add native windows on arm64 support

[Andres Freund]

Hi,

On 2024-02-12 12:50:12 -0800, Andres Freund wrote:
> On 2024-02-12 13:28:40 -0500, Andrew Dunstan wrote:
> I wonder if this indicates that we are either missing memory barriers
> somewhere or that the memory barriers we end up with on msvc + arm aren't
> correct?  Either could explain why the problem doesn't occur when building
> with optimizations.

I think I might have been on to something - if my human emulation of a
preprocessor isn't wrong, we'd end up with

#define S_UNLOCK(lock)  \
do { _ReadWriteBarrier(); (*(lock)) = 0; } while (0)

on msvc + arm. And that's entirely insufficient - _ReadWriteBarrier() just
limits *compiler* level reordering, not CPU level reordering.  I think it's
even insufficient on x86[-64], but it's definitely insufficient on arm.



Another issue I see is that we have a bunch of code that's dependant on
__aarch64__ being set - but it doesn't look to me that it is set on msvc. One
obvious consequence of that is that 64bit atomics won't be used (see
src/include/port/atomics/arch-arm.h) - but that shouldn't cause this issue.


Greetings,

Andres Freund

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Mon, 12 Feb 2024 at 15:50, Andres Freund  wrote:

> Hi,
>
> On 2024-02-12 13:28:40 -0500, Andrew Dunstan wrote:
> > On 2024-02-12 Mo 11:44, Dave Cramer wrote:
> > > OK, so I have managed to get a debugger attached to postgres.exe when
> it
> > > faults and the fault occurs at
> > >
> https://github.com/postgres/postgres/blob/09eb633e1baa3b7cd7929f3cc77f9c46f63c20b1/src/backend/utils/mmgr/dsa.c#L869
> > > span is pointing to 0x0
> >
> > Further data point. If I select a build type of 'debug' instead of
> > 'debugoptimized' the error disappears.
>
> Oh, this is quite interesting.  Dave, could you post the backtrace?
>

Andres,

I am using Visual Studio as the debugger. Here is what I have.

> postgres.exe!dsa_free(dsa_area * area, unsigned __int64 dp) Line 869 C
  postgres.exe!resize(dshash_table * hash_table, unsigned __int64
new_size_log2) Line 879 C
  postgres.exe!dshash_find_or_insert(dshash_table * hash_table, const void
* key, bool * found) Line 480 C
  postgres.exe!pgstat_get_entry_ref(PgStat_Kind kind, unsigned int dboid,
unsigned int objoid, bool create, bool * created_entry) Line 455 C
  postgres.exe!pgstat_prep_pending_entry(PgStat_Kind kind, unsigned int
dboid, unsigned int objoid, bool * created_entry) Line 1123 C
  [Inline Frame] postgres.exe!pgstat_prep_relation_pending(unsigned int)
Line 904 C
  postgres.exe!pgstat_assoc_relation(RelationData * rel) Line 139 C
  [Inline Frame] postgres.exe!ReadBufferExtended(RelationData *) Line 802 C
  postgres.exe!ReadBuffer(RelationData * reln, unsigned int blockNum) Line
737 C
  postgres.exe!read_seq_tuple(RelationData * rel, int * buf, HeapTupleData
* seqdatatuple) Line 1196 C
  postgres.exe!AlterSequence(ParseState * pstate, AlterSeqStmt * stmt) Line
481 C
  postgres.exe!ProcessUtilitySlow(ParseState * pstate, PlannedStmt * pstmt,
const char * queryString, ProcessUtilityContext context, ParamListInfoData
* params, QueryEnvironment * queryEnv, _DestReceiver * dest,
QueryCompletion * qc) Line 1679 C
  postgres.exe!standard_ProcessUtility(PlannedStmt * pstmt, const char *
queryString, bool readOnlyTree, ProcessUtilityContext context,
ParamListInfoData * params, QueryEnvironment * queryEnv, _DestReceiver *
dest, QueryCompletion * qc) Line 1080 C
  postgres.exe!ProcessUtility(PlannedStmt * pstmt, const char *
queryString, bool readOnlyTree, ProcessUtilityContext context,
ParamListInfoData * params, QueryEnvironment * queryEnv, _DestReceiver *
dest, QueryCompletion * qc) Line 530 C
  postgres.exe!ProcessUtilitySlow(ParseState * pstate, PlannedStmt * pstmt,
const char * queryString, ProcessUtilityContext context, ParamListInfoData
* params, QueryEnvironment * queryEnv, _DestReceiver * dest,
QueryCompletion * qc) Line 1263 C
  postgres.exe!standard_ProcessUtility(PlannedStmt * pstmt, const char *
queryString, bool readOnlyTree, ProcessUtilityContext context,
ParamListInfoData * params, QueryEnvironment * queryEnv, _DestReceiver *
dest, QueryCompletion * qc) Line 1080 C


if there is a better debugger to use, please let me know

Dave



>
> I wonder if this indicates that we are either missing memory barriers
> somewhere or that the memory barriers we end up with on msvc + arm aren't
> correct?  Either could explain why the problem doesn't occur when building
> with optimizations.
>
> Greetings,
>
> Andres Freund
>

Re: [PATCH] Add native windows on arm64 support

[Andres Freund]

Hi,

On 2024-02-09 15:32:10 -0500, Dave Cramer wrote:
> On Fri, 9 Feb 2024 at 14:36, Andres Freund  wrote:
> > That's something like a segfault.
> >
> > One suspicion I have is that src/port/pg_crc32c_armv8_choose.c possibly
> > doesn't properly support msvc.  It seems to assume that SIGILL can be
> > trapped,
> > but that IIRC doesn't work on windows.
> >
> > I'd check if the problem persists if you change
> > cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1)
> > to
> > cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 0)
> >
> 
> This results in
> 
> FAILED: src/bin/pg_checksums/pg_checksums.exe
> src/bin/pg_checksums/pg_checksums.pdb
> "link"  /MACHINE:ARM64 /OUT:src/bin/pg_checksums/pg_checksums.exe
> src/bin/pg_checksums/pg_checksums.exe.p/win32ver.res
> src/bin/pg_checksums/pg_checksums.exe.p/pg_checksums.c.obj "/release"
> "/nologo" "/DEBUG" "/PDB:src\bin\pg_checksums\pg_checksums.pdb"
> "/INCREMENTAL:NO" "/STACK:4194304" "/NOEXP" "src/fe_utils/libpgfeutils.a"
> "src/common/libpgcommon.a" "src/port/libpgport.a" "ws2_32.lib" "ws2_32.lib"
> "ws2_32.lib" "ws2_32.lib" "/SUBSYSTEM:CONSOLE" "kernel32.lib" "user32.lib"
> "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib"
> "uuid.lib" "comdlg32.lib" "advapi32.lib"
> libpgcommon.a(controldata_utils.c.obj) : error LNK2001: unresolved external
> symbol pg_comp_crc32c

That's because have_optimized_crc ends up being set.


I'm somewhat unhappy about the msvc specific path in meson.build. Shouldn't at
the very least the "Use ARM CRC Extension unconditionally" path be first. I
guess it's not really this patch's fault that the runtime detection for armv8
crc is implemented this shoddily :(.

Greetings,

Andres Freund

Re: [PATCH] Add native windows on arm64 support

[Andres Freund]

Hi,

On 2024-02-12 13:28:40 -0500, Andrew Dunstan wrote:
> On 2024-02-12 Mo 11:44, Dave Cramer wrote:
> > OK, so I have managed to get a debugger attached to postgres.exe when it
> > faults and the fault occurs at
> > https://github.com/postgres/postgres/blob/09eb633e1baa3b7cd7929f3cc77f9c46f63c20b1/src/backend/utils/mmgr/dsa.c#L869
> > span is pointing to 0x0
> 
> Further data point. If I select a build type of 'debug' instead of
> 'debugoptimized' the error disappears.

Oh, this is quite interesting.  Dave, could you post the backtrace?

I wonder if this indicates that we are either missing memory barriers
somewhere or that the memory barriers we end up with on msvc + arm aren't
correct?  Either could explain why the problem doesn't occur when building
with optimizations.

Greetings,

Andres Freund

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-02-12 Mo 11:44, Dave Cramer wrote:


Dave Cramer
www.postgres.rocks


On Mon, 12 Feb 2024 at 09:19, Andrew Dunstan  wrote:


On 2024-02-12 Mo 08:51, Dave Cramer wrote:



On Sat, 10 Feb 2024 at 13:28, Andrew Dunstan
 wrote:


On 2024-02-10 Sa 12:20, Dave Cramer wrote:



On Sat, 10 Feb 2024 at 11:19, Andrew Dunstan
 wrote:


On 2024-02-09 Fr 14:23, Dave Cramer wrote:


Dave Cramer
www.postgres.rocks 


On Fri, 9 Feb 2024 at 07:18, Dave Cramer

 wrote:





On Fri, 9 Feb 2024 at 00:26, Michael Paquier
 wrote:

On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave
Cramer wrote:
> Thanks, this patch works and
> testing with meson passes.

Only with the version posted at [1]? 
Interesting, that's the same
contents as v8 posted upthread, minus
src/tools/ because we don't need
to care about them anymore.

Andrew, what's happening on the test side?  It
does not seem you've
mentioned any details about what is going
wrong, or I have just missed
them.

> I'll try the buildfarm next.

[1]:

https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net


interestingly meson test does not produce any error
The buildfarm produces the following error for me:

-SELECT relname, attname, coltypes,
get_columns_length(coltypes)
- FROM check_columns
- WHERE get_columns_length(coltypes) % 8 != 0 OR
-  'name'::regtype::oid = ANY(coltypes);
- relname | attname | coltypes | get_columns_length
--+-+--+
-(0 rows)
-
+server closed the connection unexpectedly
+This probably means the server terminated abnormally
+before or while processing the request.
+connection to server was lost


Actually digging some more, here is the actual error

2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:
 server process (PID 11204) was terminated by exception
0xC005
2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:
 Failed process was running: VACUUM;
2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:
 See C include file "ntstatus.h" for a description of
the hexadecimal value.
2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:
 terminating any other active server processes
2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all
server processes terminated; reinitializing
2024-02-09 13:31:11.034 -05 startup[6152] LOG:
 database system was interrupted; last known up at
2024-02-09 13:31:01 -05






So how does one debug this ?

Also if I `run meson test` I don't see this error. What does
the buildfarm do differently?



First it does this:


meson test -C $pgsql --no-rebuild --suite setup


Then it does this (jflag is for the number of jobs):


meson test -t $meson_test_timeout $jflag -C $pgsql
--logbase checklog --print-errorlogs --no-rebuild --suite
regress --test-args=--no-locale



running the above manually produces no errors ??




Not for me. I get the error I previously reported, It's an access
violation error.




OK, so I have managed to get a debugger attached to postgres.exe when 
it faults and the fault occurs at

https://github.com/postgres/postgres/blob/09eb633e1baa3b7cd7929f3cc77f9c46f63c20b1/src/backend/utils/mmgr/dsa.c#L869
span is pointing to 0x0




Further data point. If I select a build type of 'debug' instead of 
'debugoptimized' the error disappears.



cheers


andrew

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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Mon, 12 Feb 2024 at 09:19, Andrew Dunstan  wrote:

>
> On 2024-02-12 Mo 08:51, Dave Cramer wrote:
>
>
>
> On Sat, 10 Feb 2024 at 13:28, Andrew Dunstan  wrote:
>
>>
>> On 2024-02-10 Sa 12:20, Dave Cramer wrote:
>>
>>
>>
>> On Sat, 10 Feb 2024 at 11:19, Andrew Dunstan  wrote:
>>
>>>
>>> On 2024-02-09 Fr 14:23, Dave Cramer wrote:
>>>
>>>
>>> Dave Cramer
>>> www.postgres.rocks
>>>
>>>
>>> On Fri, 9 Feb 2024 at 07:18, Dave Cramer 
>>>  wrote:
>>>




 On Fri, 9 Feb 2024 at 00:26, Michael Paquier 
 wrote:

> On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
> > Thanks, this patch works and
> > testing with meson passes.
>
> Only with the version posted at [1]?  Interesting, that's the same
> contents as v8 posted upthread, minus src/tools/ because we don't need
> to care about them anymore.
>
> Andrew, what's happening on the test side?  It does not seem you've
> mentioned any details about what is going wrong, or I have just missed
> them.
>
> > I'll try the buildfarm next.
>
> [1]:
> https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net


 interestingly meson test does not produce any error
 The buildfarm produces the following error for me:

 -SELECT relname, attname, coltypes, get_columns_length(coltypes)
 - FROM check_columns
 - WHERE get_columns_length(coltypes) % 8 != 0 OR
 -   'name'::regtype::oid = ANY(coltypes);
 - relname | attname | coltypes | get_columns_length
 --+-+--+
 -(0 rows)
 -
 +server closed the connection unexpectedly
 + This probably means the server terminated abnormally
 + before or while processing the request.
 +connection to server was lost

>>>
>>> Actually digging some more, here is the actual error
>>>
>>> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
>>> 11204) was terminated by exception 0xC005
>>> 2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process
>>> was running: VACUUM;
>>> 2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
>>> "ntstatus.h" for a description of the hexadecimal value.
>>> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  terminating any
>>> other active server processes
>>> 2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all server
>>> processes terminated; reinitializing
>>> 2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database system was
>>> interrupted; last known up at 2024-02-09 13:31:01 -05
>>>
>>>
>>>
>>>
>>>
>> So how does one debug this ?
>>
>> Also if I `run meson test` I don't see this error. What does the
>> buildfarm do differently?
>>
>>
>> First it does this:
>>
>>
>> meson test -C $pgsql --no-rebuild --suite setup
>>
>>
>> Then it does this (jflag is for the number of jobs):
>>
>>
>> meson test -t $meson_test_timeout $jflag -C $pgsql --logbase checklog
>> --print-errorlogs --no-rebuild --suite regress --test-args=--no-locale
>>
>>
>
> running the above manually produces no errors ??
>
>
>
> Not for me. I get the error I previously reported, It's an access
> violation error.
>
>
> cheers
>
>
> andrew
>

OK, so I have managed to get a debugger attached to postgres.exe when it
faults and the fault occurs at
https://github.com/postgres/postgres/blob/09eb633e1baa3b7cd7929f3cc77f9c46f63c20b1/src/backend/utils/mmgr/dsa.c#L869
span is pointing to 0x0

Dave

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-02-12 Mo 08:51, Dave Cramer wrote:



On Sat, 10 Feb 2024 at 13:28, Andrew Dunstan  wrote:


On 2024-02-10 Sa 12:20, Dave Cramer wrote:



On Sat, 10 Feb 2024 at 11:19, Andrew Dunstan
 wrote:


On 2024-02-09 Fr 14:23, Dave Cramer wrote:


Dave Cramer
www.postgres.rocks 


On Fri, 9 Feb 2024 at 07:18, Dave Cramer

 wrote:





On Fri, 9 Feb 2024 at 00:26, Michael Paquier
 wrote:

On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave
Cramer wrote:
> Thanks, this patch works and
> testing with meson passes.

Only with the version posted at [1]?  Interesting,
that's the same
contents as v8 posted upthread, minus src/tools/
because we don't need
to care about them anymore.

Andrew, what's happening on the test side?  It does
not seem you've
mentioned any details about what is going wrong, or
I have just missed
them.

> I'll try the buildfarm next.

[1]:

https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net


interestingly meson test does not produce any error
The buildfarm produces the following error for me:

-SELECT relname, attname, coltypes,
get_columns_length(coltypes)
- FROM check_columns
- WHERE get_columns_length(coltypes) % 8 != 0 OR
-  'name'::regtype::oid = ANY(coltypes);
- relname | attname | coltypes | get_columns_length
--+-+--+
-(0 rows)
-
+server closed the connection unexpectedly
+This probably means the server terminated abnormally
+before or while processing the request.
+connection to server was lost


Actually digging some more, here is the actual error

2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server
process (PID 11204) was terminated by exception 0xC005
2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:
 Failed process was running: VACUUM;
2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C
include file "ntstatus.h" for a description of the
hexadecimal value.
2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:
 terminating any other active server processes
2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all
server processes terminated; reinitializing
2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database
system was interrupted; last known up at 2024-02-09 13:31:01 -05






So how does one debug this ?

Also if I `run meson test` I don't see this error. What does the
buildfarm do differently?



First it does this:


meson test -C $pgsql --no-rebuild --suite setup


Then it does this (jflag is for the number of jobs):


meson test -t $meson_test_timeout $jflag -C $pgsql --logbase
checklog --print-errorlogs --no-rebuild --suite regress
--test-args=--no-locale



running the above manually produces no errors ??




Not for me. I get the error I previously reported, It's an access 
violation error.



cheers


andrew


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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Sat, 10 Feb 2024 at 13:28, Andrew Dunstan  wrote:

>
> On 2024-02-10 Sa 12:20, Dave Cramer wrote:
>
>
>
> On Sat, 10 Feb 2024 at 11:19, Andrew Dunstan  wrote:
>
>>
>> On 2024-02-09 Fr 14:23, Dave Cramer wrote:
>>
>>
>> Dave Cramer
>> www.postgres.rocks
>>
>>
>> On Fri, 9 Feb 2024 at 07:18, Dave Cramer 
>>  wrote:
>>
>>>
>>>
>>>
>>>
>>> On Fri, 9 Feb 2024 at 00:26, Michael Paquier 
>>> wrote:
>>>
 On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
 > Thanks, this patch works and
 > testing with meson passes.

 Only with the version posted at [1]?  Interesting, that's the same
 contents as v8 posted upthread, minus src/tools/ because we don't need
 to care about them anymore.

 Andrew, what's happening on the test side?  It does not seem you've
 mentioned any details about what is going wrong, or I have just missed
 them.

 > I'll try the buildfarm next.

 [1]:
 https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net
>>>
>>>
>>> interestingly meson test does not produce any error
>>> The buildfarm produces the following error for me:
>>>
>>> -SELECT relname, attname, coltypes, get_columns_length(coltypes)
>>> - FROM check_columns
>>> - WHERE get_columns_length(coltypes) % 8 != 0 OR
>>> -   'name'::regtype::oid = ANY(coltypes);
>>> - relname | attname | coltypes | get_columns_length
>>> --+-+--+
>>> -(0 rows)
>>> -
>>> +server closed the connection unexpectedly
>>> + This probably means the server terminated abnormally
>>> + before or while processing the request.
>>> +connection to server was lost
>>>
>>
>> Actually digging some more, here is the actual error
>>
>> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
>> 11204) was terminated by exception 0xC005
>> 2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process
>> was running: VACUUM;
>> 2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
>> "ntstatus.h" for a description of the hexadecimal value.
>> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  terminating any
>> other active server processes
>> 2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all server processes
>> terminated; reinitializing
>> 2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database system was
>> interrupted; last known up at 2024-02-09 13:31:01 -05
>>
>>
>>
>>
>>
> So how does one debug this ?
>
> Also if I `run meson test` I don't see this error. What does the buildfarm
> do differently?
>
>
> First it does this:
>
>
> meson test -C $pgsql --no-rebuild --suite setup
>
>
> Then it does this (jflag is for the number of jobs):
>
>
> meson test -t $meson_test_timeout $jflag -C $pgsql --logbase checklog
> --print-errorlogs --no-rebuild --suite regress --test-args=--no-locale
>
>

running the above manually produces no errors ??

Dave

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-02-10 Sa 12:20, Dave Cramer wrote:



On Sat, 10 Feb 2024 at 11:19, Andrew Dunstan  wrote:


On 2024-02-09 Fr 14:23, Dave Cramer wrote:


Dave Cramer
www.postgres.rocks 


On Fri, 9 Feb 2024 at 07:18, Dave Cramer
  wrote:





On Fri, 9 Feb 2024 at 00:26, Michael Paquier
 wrote:

On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
> Thanks, this patch works and
> testing with meson passes.

Only with the version posted at [1]? Interesting, that's
the same
contents as v8 posted upthread, minus src/tools/ because
we don't need
to care about them anymore.

Andrew, what's happening on the test side?  It does not
seem you've
mentioned any details about what is going wrong, or I
have just missed
them.

> I'll try the buildfarm next.

[1]:

https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net


interestingly meson test does not produce any error
The buildfarm produces the following error for me:

-SELECT relname, attname, coltypes, get_columns_length(coltypes)
- FROM check_columns
- WHERE get_columns_length(coltypes) % 8 != 0 OR
-       'name'::regtype::oid = ANY(coltypes);
- relname | attname | coltypes | get_columns_length
--+-+--+
-(0 rows)
-
+server closed the connection unexpectedly
+This probably means the server terminated abnormally
+before or while processing the request.
+connection to server was lost


Actually digging some more, here is the actual error

2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server
process (PID 11204) was terminated by exception 0xC005
2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed
process was running: VACUUM;
2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C
include file "ntstatus.h" for a description of the hexadecimal value.
2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  terminating
any other active server processes
2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all server
processes terminated; reinitializing
2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database system
was interrupted; last known up at 2024-02-09 13:31:01 -05






So how does one debug this ?

Also if I `run meson test` I don't see this error. What does the 
buildfarm do differently?



First it does this:


   meson test -C $pgsql --no-rebuild --suite setup


Then it does this (jflag is for the number of jobs):


   meson test -t $meson_test_timeout $jflag -C $pgsql --logbase
   checklog --print-errorlogs --no-rebuild --suite regress
   --test-args=--no-locale


cheers


andrew

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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Sat, 10 Feb 2024 at 11:19, Andrew Dunstan  wrote:

>
> On 2024-02-09 Fr 14:23, Dave Cramer wrote:
>
>
> Dave Cramer
> www.postgres.rocks
>
>
> On Fri, 9 Feb 2024 at 07:18, Dave Cramer 
>  wrote:
>
>>
>>
>>
>>
>> On Fri, 9 Feb 2024 at 00:26, Michael Paquier  wrote:
>>
>>> On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
>>> > Thanks, this patch works and
>>> > testing with meson passes.
>>>
>>> Only with the version posted at [1]?  Interesting, that's the same
>>> contents as v8 posted upthread, minus src/tools/ because we don't need
>>> to care about them anymore.
>>>
>>> Andrew, what's happening on the test side?  It does not seem you've
>>> mentioned any details about what is going wrong, or I have just missed
>>> them.
>>>
>>> > I'll try the buildfarm next.
>>>
>>> [1]:
>>> https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net
>>
>>
>> interestingly meson test does not produce any error
>> The buildfarm produces the following error for me:
>>
>> -SELECT relname, attname, coltypes, get_columns_length(coltypes)
>> - FROM check_columns
>> - WHERE get_columns_length(coltypes) % 8 != 0 OR
>> -   'name'::regtype::oid = ANY(coltypes);
>> - relname | attname | coltypes | get_columns_length
>> --+-+--+
>> -(0 rows)
>> -
>> +server closed the connection unexpectedly
>> + This probably means the server terminated abnormally
>> + before or while processing the request.
>> +connection to server was lost
>>
>
> Actually digging some more, here is the actual error
>
> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
> 11204) was terminated by exception 0xC005
> 2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process was
> running: VACUUM;
> 2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
> "ntstatus.h" for a description of the hexadecimal value.
> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  terminating any other
> active server processes
> 2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all server processes
> terminated; reinitializing
> 2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database system was
> interrupted; last known up at 2024-02-09 13:31:01 -05
>
>
>
>
>
So how does one debug this ?

Also if I `run meson test` I don't see this error. What does the buildfarm
do differently?

Dave

> Yes, this is pretty much what I saw.
>
>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
>

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-02-09 Fr 14:23, Dave Cramer wrote:


Dave Cramer
www.postgres.rocks


On Fri, 9 Feb 2024 at 07:18, Dave Cramer  
wrote:






On Fri, 9 Feb 2024 at 00:26, Michael Paquier 
wrote:

On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
> Thanks, this patch works and
> testing with meson passes.

Only with the version posted at [1]?  Interesting, that's the same
contents as v8 posted upthread, minus src/tools/ because we
don't need
to care about them anymore.

Andrew, what's happening on the test side?  It does not seem
you've
mentioned any details about what is going wrong, or I have
just missed
them.

> I'll try the buildfarm next.

[1]:

https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net


interestingly meson test does not produce any error
The buildfarm produces the following error for me:

-SELECT relname, attname, coltypes, get_columns_length(coltypes)
- FROM check_columns
- WHERE get_columns_length(coltypes) % 8 != 0 OR
-       'name'::regtype::oid = ANY(coltypes);
- relname | attname | coltypes | get_columns_length
--+-+--+
-(0 rows)
-
+server closed the connection unexpectedly
+This probably means the server terminated abnormally
+before or while processing the request.
+connection to server was lost


Actually digging some more, here is the actual error

2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process 
(PID 11204) was terminated by exception 0xC005
2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process 
was running: VACUUM;
2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include 
file "ntstatus.h" for a description of the hexadecimal value.
2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  terminating any 
other active server processes
2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all server 
processes terminated; reinitializing
2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database system was 
interrupted; last known up at 2024-02-09 13:31:01 -05






Yes, this is pretty much what I saw.


cheers


andrew

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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Fri, 9 Feb 2024 at 14:36, Andres Freund  wrote:

> Hi,
>
> On 2024-02-09 14:23:46 -0500, Dave Cramer wrote:
> > > interestingly meson test does not produce any error
> > > The buildfarm produces the following error for me:
> > >
> > > -SELECT relname, attname, coltypes, get_columns_length(coltypes)
> > > - FROM check_columns
> > > - WHERE get_columns_length(coltypes) % 8 != 0 OR
> > > -   'name'::regtype::oid = ANY(coltypes);
> > > - relname | attname | coltypes | get_columns_length
> > > --+-+--+
> > > -(0 rows)
> > > -
> > > +server closed the connection unexpectedly
> > > + This probably means the server terminated abnormally
> > > + before or while processing the request.
> > > +connection to server was lost
> > >
> >
> > Actually digging some more, here is the actual error
> >
> > 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
> > 11204) was terminated by exception 0xC005
> > 2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process was
> > running: VACUUM;
> > 2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
> > "ntstatus.h" for a description of the hexadecimal value.
>
> That's something like a segfault.
>
> One suspicion I have is that src/port/pg_crc32c_armv8_choose.c possibly
> doesn't properly support msvc.  It seems to assume that SIGILL can be
> trapped,
> but that IIRC doesn't work on windows.
>
> I'd check if the problem persists if you change
> cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1)
> to
> cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 0)
>

This results in

FAILED: src/bin/pg_checksums/pg_checksums.exe
src/bin/pg_checksums/pg_checksums.pdb
"link"  /MACHINE:ARM64 /OUT:src/bin/pg_checksums/pg_checksums.exe
src/bin/pg_checksums/pg_checksums.exe.p/win32ver.res
src/bin/pg_checksums/pg_checksums.exe.p/pg_checksums.c.obj "/release"
"/nologo" "/DEBUG" "/PDB:src\bin\pg_checksums\pg_checksums.pdb"
"/INCREMENTAL:NO" "/STACK:4194304" "/NOEXP" "src/fe_utils/libpgfeutils.a"
"src/common/libpgcommon.a" "src/port/libpgport.a" "ws2_32.lib" "ws2_32.lib"
"ws2_32.lib" "ws2_32.lib" "/SUBSYSTEM:CONSOLE" "kernel32.lib" "user32.lib"
"gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib"
"uuid.lib" "comdlg32.lib" "advapi32.lib"
libpgcommon.a(controldata_utils.c.obj) : error LNK2001: unresolved external
symbol pg_comp_crc32c


Dave


>
>
> Also, yikes, that's an ugly way of doing hardware detection. Jumping out
> of a
> signal handler into normal code. Brrr.
>
> Greetings,
>
> Andres Freund
>

Re: [PATCH] Add native windows on arm64 support

[Andres Freund]

Hi,

On 2024-02-09 14:23:46 -0500, Dave Cramer wrote:
> > interestingly meson test does not produce any error
> > The buildfarm produces the following error for me:
> >
> > -SELECT relname, attname, coltypes, get_columns_length(coltypes)
> > - FROM check_columns
> > - WHERE get_columns_length(coltypes) % 8 != 0 OR
> > -   'name'::regtype::oid = ANY(coltypes);
> > - relname | attname | coltypes | get_columns_length
> > --+-+--+
> > -(0 rows)
> > -
> > +server closed the connection unexpectedly
> > + This probably means the server terminated abnormally
> > + before or while processing the request.
> > +connection to server was lost
> >
> 
> Actually digging some more, here is the actual error
> 
> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
> 11204) was terminated by exception 0xC005
> 2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process was
> running: VACUUM;
> 2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
> "ntstatus.h" for a description of the hexadecimal value.

That's something like a segfault.

One suspicion I have is that src/port/pg_crc32c_armv8_choose.c possibly
doesn't properly support msvc.  It seems to assume that SIGILL can be trapped,
but that IIRC doesn't work on windows.

I'd check if the problem persists if you change
cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1)
to
cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 0)


Also, yikes, that's an ugly way of doing hardware detection. Jumping out of a
signal handler into normal code. Brrr.

Greetings,

Andres Freund

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Fri, 9 Feb 2024 at 07:18, Dave Cramer  wrote:

>
>
>
>
> On Fri, 9 Feb 2024 at 00:26, Michael Paquier  wrote:
>
>> On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
>> > Thanks, this patch works and
>> > testing with meson passes.
>>
>> Only with the version posted at [1]?  Interesting, that's the same
>> contents as v8 posted upthread, minus src/tools/ because we don't need
>> to care about them anymore.
>>
>> Andrew, what's happening on the test side?  It does not seem you've
>> mentioned any details about what is going wrong, or I have just missed
>> them.
>>
>> > I'll try the buildfarm next.
>>
>> [1]:
>> https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net
>
>
> interestingly meson test does not produce any error
> The buildfarm produces the following error for me:
>
> -SELECT relname, attname, coltypes, get_columns_length(coltypes)
> - FROM check_columns
> - WHERE get_columns_length(coltypes) % 8 != 0 OR
> -   'name'::regtype::oid = ANY(coltypes);
> - relname | attname | coltypes | get_columns_length
> --+-+--+
> -(0 rows)
> -
> +server closed the connection unexpectedly
> + This probably means the server terminated abnormally
> + before or while processing the request.
> +connection to server was lost
>

Actually digging some more, here is the actual error

2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
11204) was terminated by exception 0xC005
2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process was
running: VACUUM;
2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
"ntstatus.h" for a description of the hexadecimal value.
2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  terminating any other
active server processes
2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all server processes
terminated; reinitializing
2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database system was
interrupted; last known up at 2024-02-09 13:31:01 -05


Dave

>
> Dave
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Fri, 9 Feb 2024 at 00:26, Michael Paquier  wrote:

> On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
> > Thanks, this patch works and
> > testing with meson passes.
>
> Only with the version posted at [1]?  Interesting, that's the same
> contents as v8 posted upthread, minus src/tools/ because we don't need
> to care about them anymore.
>
> Andrew, what's happening on the test side?  It does not seem you've
> mentioned any details about what is going wrong, or I have just missed
> them.
>
> > I'll try the buildfarm next.
>
> [1]:
> https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net


interestingly meson test does not produce any error
The buildfarm produces the following error for me:

-SELECT relname, attname, coltypes, get_columns_length(coltypes)
- FROM check_columns
- WHERE get_columns_length(coltypes) % 8 != 0 OR
-   'name'::regtype::oid = ANY(coltypes);
- relname | attname | coltypes | get_columns_length
--+-+--+
-(0 rows)
-
+server closed the connection unexpectedly
+ This probably means the server terminated abnormally
+ before or while processing the request.
+connection to server was lost

Dave

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
> Thanks, this patch works and
> testing with meson passes.

Only with the version posted at [1]?  Interesting, that's the same
contents as v8 posted upthread, minus src/tools/ because we don't need
to care about them anymore.

Andrew, what's happening on the test side?  It does not seem you've
mentioned any details about what is going wrong, or I have just missed
them.

> I'll try the buildfarm next.

[1]: 
https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net
--
Michael


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Wed, 31 Jan 2024 at 10:21, Andrew Dunstan  wrote:

>
> On 2024-01-30 Tu 17:54, Dave Cramer wrote:
>
>
>
>
> On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan 
> wrote:
>
>>
>> On 2024-01-30 Tu 09:50, Dave Cramer wrote:
>>
>>
>>
>> On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan  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 
>>> wrote:
>>>

 On 2024-01-26 Fr 09:18, Dave Cramer wrote:



 On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan 
 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 
> 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
> 
> 
>
> 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
>
>

Thanks, this patch works and
testing with meon passes.

I'll try the buildfarm next.

Dave

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

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

Re: [PATCH] Add native windows on arm64 support

[Peter Eisentraut]

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?

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-01-30 Tu 17:54, Dave Cramer wrote:




On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan  
wrote:



On 2024-01-30 Tu 09:50, Dave Cramer wrote:



On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan
 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
 wrote:


On 2024-01-26 Fr 09:18, Dave Cramer wrote:



On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan
 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
 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 



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



cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index ed5b285a5e..d9b8649dab 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -4150,7 +4150,7 @@ make: *** [postgres] Error 1

 Special Considerations for 64-Bit Windows
 
- 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.
 
 
  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 
+#else
 #include 
-
+#endif
 int main(void)
 {
 unsigned int crc = 0;
@@ -2061,7 +2064,11 @@ int main(void)
 }
 '''
 
-  if cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan  wrote:

>
> On 2024-01-30 Tu 09:50, Dave Cramer wrote:
>
>
>
> On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan  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  wrote:
>>
>>>
>>> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>>
>>>
>>>
>>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan 
>>> 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 
 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
>
>

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-01-30 Tu 09:50, Dave Cramer wrote:



On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan  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
 wrote:


On 2024-01-26 Fr 09:18, Dave Cramer wrote:



On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan
 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
 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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan  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  wrote:
>
>>
>> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>
>>
>>
>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan  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 
>>> 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


0001-fix-build-for-arm.patch
Description: Binary data


0002-naive-patch-to-fix-locking-for-arm64.patch
Description: Binary data

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

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  wrote:


On 2024-01-26 Fr 09:18, Dave Cramer wrote:



On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan
 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
 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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan  wrote:

>
> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>
>
>
> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan  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 
>> 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

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-01-26 Fr 09:18, Dave Cramer wrote:



On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan  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
 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

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-01-26 Fr 09:18, Dave Cramer wrote:



On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan  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
 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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan  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 
> 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 :(

>
>


lock.patch
Description: Binary data

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

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  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

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan  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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan  wrote:

>
> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>
>
>
> On Thu, 25 Jan 2024 at 16:04, Anthony Roberts 
> 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

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-01-25 Th 16:17, Dave Cramer wrote:



On Thu, 25 Jan 2024 at 16:04, Anthony Roberts 
 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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 16:04, Anthony Roberts 
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

>

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2024-01-25 Th 15:56, Dave Cramer wrote:



On Thu, 25 Jan 2024 at 14:31, Andrew Dunstan  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

Re: [PATCH] Add native windows on arm64 support

[Anthony Roberts]

Hi David,

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

Thanks,
Anthony

On Thu, 25 Jan 2024, 21:01 Dave Cramer,  wrote:

>
>
> On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan  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
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan  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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 14:31, Andrew Dunstan  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

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan  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

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 08:31, Dave Cramer  wrote:

>
>
> On Wed, 24 Jan 2024 at 19:03, 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].
>>
>
> 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

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Wed, 24 Jan 2024 at 19:03, 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].
>

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

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 23 Jan 2024 at 18:32, Michael Paquier  wrote:

> On Tue, Jan 23, 2024 at 04:13:05PM -0500, Dave Cramer wrote:
> > On Tue, 23 Jan 2024 at 08:46, Dave Cramer 
> 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

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

On Tue, Jan 23, 2024 at 04:13:05PM -0500, Dave Cramer wrote:
> On Tue, 23 Jan 2024 at 08:46, Dave Cramer  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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 23 Jan 2024 at 08:46, Dave Cramer  wrote:

>
>
> On Tue, 19 Sept 2023 at 23:48, Michael Paquier 
> 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/dbd80715-e56b-40eb-84aa-ace70198e...@yesql.se
>>
>> https://www.postgresql.org/message-id/6d1e2719-fa49-42a5-a6ff-0b0072bf6...@yesql.se
>> --
>> 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

>
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 19 Sept 2023 at 23:48, Michael Paquier  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/dbd80715-e56b-40eb-84aa-ace70198e...@yesql.se
>
> https://www.postgresql.org/message-id/6d1e2719-fa49-42a5-a6ff-0b0072bf6...@yesql.se
> --
> Michael
>

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


windows_arm_build.patch
Description: Binary data

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

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/dbd80715-e56b-40eb-84aa-ace70198e...@yesql.se
https://www.postgresql.org/message-id/6d1e2719-fa49-42a5-a6ff-0b0072bf6...@yesql.se
--
Michael


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Anthony Roberts]

Hi,

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


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


Thanks,
Anthony

On 19/09/2023 09:33, Peter Eisentraut wrote:

On 14.09.23 11:39, Daniel Gustafsson wrote:
On 13 Sep 2023, at 21:12, Peter Eisentraut  
wrote:


On 31.08.23 06:44, Tom Lane wrote:

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


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


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


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

Re: [PATCH] Add native windows on arm64 support

[Peter Eisentraut]

On 14.09.23 11:39, Daniel Gustafsson wrote:

On 13 Sep 2023, at 21:12, Peter Eisentraut  wrote:

On 31.08.23 06:44, Tom Lane wrote:

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


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


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


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

Re: [PATCH] Add native windows on arm64 support

[Daniel Gustafsson]

> On 13 Sep 2023, at 21:12, Peter Eisentraut  wrote:
> 
> On 31.08.23 06:44, Tom Lane wrote:
>> I agree.  I'm really uncomfortable with claiming support for
>> Windows-on-ARM if we don't have a buildfarm member testing it.
>> For other platforms that have a track record of multiple
>> hardware support, it might not be a stretch ... but Windows was
>> so resolutely Intel-only for so long that "it works on ARM" is
>> a proposition that I won't trust without hard evidence.  There
>> are too many bits of that system that might not have gotten the
>> word yet, or at least not gotten sufficient testing.
>> My vote for this is we don't commit without a buildfarm member.
> 
> I think we can have a multi-tiered approach, where we can commit support but 
> consider it experimental until we have buildfarm coverage.

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

--
Daniel Gustafsson

Re: [PATCH] Add native windows on arm64 support

[Peter Eisentraut]

On 31.08.23 06:44, Tom Lane wrote:

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

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


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

Re: [PATCH] Add native windows on arm64 support

[Andres Freund]

Hi,

On 2023-08-31 14:33:56 +0900, Michael Paquier wrote:
> On Thu, Aug 31, 2023 at 01:06:53AM -0400, Tom Lane wrote:
> > That's a good point.  The hardware resources to support a buildfarm
> > animal are really pretty trivial these days.  What is important is
> > an animal owner who is willing to help chase down problems when they
> > arise.
> 
> Unfortunately I don't see myself running that at home.  It is too hot
> and humid in Summer so the machine would not last.  Something in the
> cloud would be OK for me, but AWS has no option for a Windows host
> with ARM yet.

FWIW, we could run ARM windows as part of CI. It'd be a bit of scripting work,
as google doesn't yet have readymade VM images with windows for ARM. Right now
the CI VM images for windows are based on top of the google images. Scripting
generation of ARM images would be some one-off work, but after that...

Greetings,

Andres Freund

Re: [PATCH] Add native windows on arm64 support

[Peter Eisentraut]

On 02.05.23 09:51, Niyas Sait wrote:

diff --git a/doc/src/sgml/install-windows.sgml 
b/doc/src/sgml/install-windows.sgml
index cbc70a039c..2ecd5fcf38 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -352,7 +352,8 @@ $ENV{MSBFLAGS}="/m";
Special Considerations for 64-Bit Windows
  


-   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.



Are there other possible architectures besides x64 and ARM64?  Itanium? 
Or should we just delete this sentence?



diff --git a/meson.build b/meson.build
index 096044628c..6cca212fae 100644
--- a/meson.build
+++ b/meson.build
@@ -2045,8 +2045,11 @@ int main(void)
  elif host_cpu == 'arm' or host_cpu == 'aarch64'
  
prog = '''

+#ifdef _MSC_VER
+#include 
+#else
  #include 
-
+#endif


Maybe keep the whitespace here.


-  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',


Add a comment here.


diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c
index d8fae510cf..3d7eb748ff 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 
+#endif


Also add a comment here.

  
  #include "port/pg_crc32c.h"
  
diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl

index e7cbefcbc3..934dc17b96 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


Is x64 the opposite of win32?  Does this make sense?  Should we reverse 
the logic here and single out the one variant where the stripping is 
necessary?

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

On Thu, Aug 31, 2023 at 01:06:53AM -0400, Tom Lane wrote:
> That's a good point.  The hardware resources to support a buildfarm
> animal are really pretty trivial these days.  What is important is
> an animal owner who is willing to help chase down problems when they
> arise.

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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Tom Lane]

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

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

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

regards, tom lane

Re: [PATCH] Add native windows on arm64 support

[Thomas Munro]

On Thu, Aug 31, 2023 at 4:22 PM Michael Paquier  wrote:
> Honestly, I am not sure how to proceed here.  Having something in the
> buildfarm is necessary IMO, because this is the central place that
> community members look at when it comes to monitoring the stability of
> a patch committed.

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

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

Re: [PATCH] Add native windows on arm64 support

[Tom Lane]

Michael Paquier  writes:
> On Wed, Aug 30, 2023 at 04:12:16PM +0100, Anthony Roberts wrote:
>> Just a follow-up: having spoken to the relevant people, sadly, right now,
>> we do not have the capacity to be pulling machines out of our day-to-day CI
>> tasks to dedicate to specific projects.

> Okay, thanks for letting us know.

Too bad.

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

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

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

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

regards, tom lane

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

On Wed, Aug 30, 2023 at 04:12:16PM +0100, Anthony Roberts wrote:
> Just a follow-up: having spoken to the relevant people, sadly, right now,
> we do not have the capacity to be pulling machines out of our day-to-day CI
> tasks to dedicate to specific projects.

Okay, thanks for letting us know.

> I can, however, offer a few alternatives:
> 
> 1. If you have capacity on your linux x64 machines, it is possible to
> emulate WoA, and run tests that way:
> https://www.linaro.org/blog/emulate-windows-on-arm/
> This is something that works well for projects that we have contributed it
> to (ie, sse2neon uses it via github actions) - if you run into any issues
> with this, we are able to try and fix them on our side, as likely more than
> postgres would benefit.
> 
> 2. If there is any scope for it on your side at all, a Samsung Galaxy Book
> Go 14" can be had from ebay for ~£140.
> Understandably, this might not be an option for you.
> 
> If it helps, if this is merged, we do have the possibility of running our
> own downstream CI builds nightly for the tip of your main branch here:
> https://gitlab.com/Linaro/windowsonarm/nightly
> This is something we do for a few projects that do not have full upstream
> CI.

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

Any opinions from the others?
--
Michael


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Anthony Roberts]

Hi,

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

I can, however, offer a few alternatives:

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

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

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

Thanks,
Anthony


On Fri, 25 Aug 2023 at 11:34, Anthony Roberts 
wrote:

> Thanks for the link - that looks basically the same as what we do for
> CMake (option 2), so should be relatively easy.
>
> I will have a chat to relevant people about setting a machine up
> properly for it.
>
> Thanks,
> Anthony
>
> On 25/08/2023 11:17, Michael Paquier wrote:
> > On Fri, Aug 25, 2023 at 10:40:39AM +0100, Anthony Roberts wrote:
> >> Which of these are you looking for us to provide:
> >>
> >> * A machine for you to directly access (via a VPN)
> >> * A machine we just run a worker script on that automatically picks up
> the
> >> builds as required
> >> * Us to do downstream CI
> >>
> >> All are possible, but preferably not option 1, as it would mean
> straight up
> >> pulling out a machine from our build farm, and it has to go through all
> >> sorts of approvals internally. If it's the only way forward I can kick
> it up
> >> the chain though.
> >>
> >> Option 2 and 3 are ones we do for various other projects (ie. 2 -
> CMake, 3 -
> >> OpenSSL)
> > The community has its own CI facility.  Here is a link of how to set
> > up a machine:
> > https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto
> >
> > And all the results are published by the maintainers of the machines
> > on a periodic basis where the buildfarm client code is set:
> > https://buildfarm.postgresql.org/cgi-bin/show_status.pl
> >
> > The final result would be for you to maintain the machine so as we are
> > able to see if anything breaks with it.  Adding extra dependencies to
> > the build like OpenSSL would be nice, but based on the contents of the
> > patch to add this port that does not seem mandatory to me, either.
> >
> > Once the machine is ready, you will need to request a buildfarm
> > machine name and a key to be able to begin publishing the reports of
> > the builds to the community buildfarm.  Once the machine is ready to
> > go, just let me know and I'd be OK to merge the patch (I still want to
> > do a final review of it in case I've missed something, but I can move
> > on with that before the buildfarm machine is set up).
> > --
> > Michael
>

Re: [PATCH] Add native windows on arm64 support

[Daniel Gustafsson]

> On 25 Aug 2023, at 11:40, Anthony Roberts  wrote:

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

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

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

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

> * Us to do downstream CI

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

http://cfbot.cputube.org/

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

--
Daniel Gustafsson

Re: [PATCH] Add native windows on arm64 support

[Anthony Roberts]

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


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


Thanks,
Anthony

On 25/08/2023 11:17, Michael Paquier wrote:

On Fri, Aug 25, 2023 at 10:40:39AM +0100, Anthony Roberts wrote:

Which of these are you looking for us to provide:

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

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

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

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

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

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

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

Re: [PATCH] Add native windows on arm64 support

[Anthony Roberts]

Hi,

Which of these are you looking for us to provide:

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

* Us to do downstream CI

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


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


Thanks,
Anthony

On 17/08/2023 23:28, Michael Paquier wrote:

On Thu, Aug 17, 2023 at 09:41:44AM +0100, Anthony Roberts wrote:

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

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

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

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

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

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

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

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

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

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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

On Thu, Aug 17, 2023 at 09:41:44AM +0100, Anthony Roberts wrote:
> Just following up on this, has there been any movement?
> 
> I did see another message go into the thread here with no reply:
> https://www.postgresql.org/message-id/ZKPLjLjIjwN2lxkg%40paquier.xyz

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

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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Anthony Roberts]

Hi All,

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

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


Thanks,
Anthony

On 14/06/2023 13:25, Niyas Sait wrote:

Hello,

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


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

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

On Thu, May 11, 2023 at 01:19:54PM +0900, Michael Paquier wrote:
> On Thu, May 11, 2023 at 12:17:25PM +1200, Thomas Munro wrote:
>> Azure does have an image "Microsoft Windows 11 Preview arm64" to run
>> on Ampere CPUs, which says it's a pre-release version intended for
>> validation, which sounds approximately like what we want.  I will try
>> to find out more.
> 
> Interesting.  Thanks for mentioning it.

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

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

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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Niyas Sait]

Hello,

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


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

--
Niyas

Re: [PATCH] Add native windows on arm64 support

[Niyas Sait]

On 11/05/2023 00:34, Michael Paquier wrote:

On Wed, May 10, 2023 at 09:24:39AM -0400, Andrew Dunstan wrote:

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

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

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


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

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


--
Niyas

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

On Thu, May 11, 2023 at 12:17:25PM +1200, Thomas Munro wrote:
> Azure does have an image "Microsoft Windows 11 Preview arm64" to run
> on Ampere CPUs, which says it's a pre-release version intended for
> validation, which sounds approximately like what we want.  I will try
> to find out more.

Interesting.  Thanks for mentioning it.
--
Michael


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Thomas Munro]

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

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

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

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

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

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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Andrew Dunstan]

On 2023-05-08 Mo 15:58, Tom Lane wrote:

Andres Freund  writes:

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

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

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

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




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




cheers


andrew

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

Re: [PATCH] Add native windows on arm64 support

[Tom Lane]

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

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

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

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

regards, tom lane

Re: [PATCH] Add native windows on arm64 support

[Andres Freund]

Hi,

On 2023-05-06 00:35:40 -0400, Tom Lane wrote:
> Michael Paquier  writes:
> > Seeing how simple this has become, I would be really tempted to get
> > that applied, especially if there's a buildfarm machine able to follow
> > up..  On the one hand, we are in a stability period for v16, so it may
> > not be the best moment ever.  On the other hand, waiting one more year
> > sounds like a waste for a patch that just adds new code paths.
> 
> Indeed, there's not much in this patch ... but it's impossible to see
> how "run on an entirely new platform" isn't a new feature.  Moreover,
> it's a platform that very few of us will have any ability to support
> or debug for.  I can't see how it's a good idea to shove this in
> post-feature-freeze.  Let's plan to push it in when v17 opens.

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

Greetings,

Andres Freund

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

On Sat, May 06, 2023 at 12:35:40AM -0400, Tom Lane wrote:
> Indeed, there's not much in this patch ... but it's impossible to see
> how "run on an entirely new platform" isn't a new feature.  Moreover,
> it's a platform that very few of us will have any ability to support
> or debug for.  I can't see how it's a good idea to shove this in
> post-feature-freeze.  Let's plan to push it in when v17 opens.

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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Tom Lane]

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

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

regards, tom lane

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

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

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

RMT members, any thoughts?
--
Michael


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Niyas Sait]

On 19/01/2023 10:09, Niyas Sait wrote:



On 17/01/2023 22:51, Andres Freund wrote:



  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)


Seems like it'd be easier to read if you don't re-indent this, but 
just have

the cc.get_id() == 'msvc' part of this if/else-if.





I've attached a new version (v8) to fix the above indentation issue.

Could someone please help with the review ?

--
NiyasFrom 108ad061caa15c7346d53e906794c4e971afbcc0 Mon Sep 17 00:00:00 2001
From: Niyas Sait 
Date: Fri, 16 Dec 2022 10:45:56 +
Subject: [PATCH v8] 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   | 11 +--
 src/include/storage/s_lock.h  | 20 ++--
 src/port/pg_crc32c_armv8.c|  2 ++
 src/tools/msvc/gendef.pl  |  8 
 5 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/doc/src/sgml/install-windows.sgml 
b/doc/src/sgml/install-windows.sgml
index cbc70a039c..2ecd5fcf38 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -352,7 +352,8 @@ $ENV{MSBFLAGS}="/m";
   Special Considerations for 64-Bit Windows
 
   
-   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.
   
 
   
diff --git a/meson.build b/meson.build
index 096044628c..6cca212fae 100644
--- a/meson.build
+++ b/meson.build
@@ -2045,8 +2045,11 @@ int main(void)
 elif host_cpu == 'arm' or host_cpu == 'aarch64'
 
   prog = '''
+#ifdef _MSC_VER
+#include 
+#else
 #include 
-
+#endif
 int main(void)
 {
 unsigned int crc = 0;
@@ -2060,7 +2063,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 c9fa84cc43..a7973eae49 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 d8fae510cf..3d7eb748ff 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 
+#endif
 
 #include "port/pg_crc32c.h"
 
diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl
index e7cbefcbc3..934dc17b96 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

Re: [PATCH] Add native windows on arm64 support

[Niyas Sait]

On 17/01/2023 22:51, Andres Freund wrote:

Hi,

On 2022-12-16 10:52:23 +, Niyas Sait wrote:

Subject: [PATCH v7] Enable postgres native build for windows-arm64 platform



  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


I dimly recall that windows might actually require the relevant extension on
arm?


Do you mean we don't need the runtime checks for CRC ?

CRC is an optional extension for ARMv8 base architecture. I am not sure 
if windows make it mandatory to have this implementation.





+  else
+prog = '''
  #include 


I'd just make this include #ifdef _MSV_VER (or whatever it is).


The code snippet is not used for MSVC part. I am not sure why we need to 
add the #ifdef _MSC_VER.



  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)


Seems like it'd be easier to read if you don't re-indent this, but just have
the cc.get_id() == 'msvc' part of this if/else-if.



Yes that looks better. will do it in next patch.

Thanks Andres for the review.

--
Niyas

Re: [PATCH] Add native windows on arm64 support

[Andres Freund]

Hi,

On 2022-12-16 10:52:23 +, Niyas Sait wrote:
> Subject: [PATCH v7] Enable postgres native build for windows-arm64 platform

>  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

I dimly recall that windows might actually require the relevant extension on
arm?


> +  else
> +prog = '''
>  #include 

I'd just make this include #ifdef _MSV_VER (or whatever it is).


>  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)

Seems like it'd be easier to read if you don't re-indent this, but just have
the cc.get_id() == 'msvc' part of this if/else-if.


Greetings,

Andres Freund

Re: [PATCH] Add native windows on arm64 support

[Niyas Sait]

On 16/12/2022 10:52, Niyas Sait wrote:

On 12/12/2022 23:56, Michael Paquier wrote:

On Mon, Dec 12, 2022 at 01:38:37PM +, 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.



Hello,

Can I get review for the latest patch please ?

--
Niyas

Re: [PATCH] Add native windows on arm64 support

[Niyas Sait]

On 12/12/2022 23:56, Michael Paquier wrote:

On Mon, Dec 12, 2022 at 01:38:37PM +, 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.



--
NiyasFrom 50e8affb5bcb3f6a50a223053fc92145a5709e82 Mon Sep 17 00:00:00 2001
From: Niyas Sait 
Date: Fri, 16 Dec 2022 10:45:56 +
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";
   Special Considerations for 64-Bit Windows
 
   
-   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.
   
 
   
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 
 
 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 
+#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 

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

On Mon, Dec 12, 2022 at 01:38:37PM +, 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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Niyas Sait]

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 
  
  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

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

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


signature.asc
Description: PGP signature

Re: [PATCH] Add native windows on arm64 support

[Andres Freund]

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

Re: [PATCH] Add native windows on arm64 support

[Michael Paquier]

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


signature.asc
Description: PGP signature