Re: [PATCH] Add native windows on arm64 support

On Sat, Feb 10, 2024 at 8:36 AM Andres Freund <andres@anarazel.de> 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 0xC000001D, 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