Re: [PATCH] Add native windows on arm64 support - Mailing list pgsql-hackers
From | Thomas Munro |
---|---|
Subject | Re: [PATCH] Add native windows on arm64 support |
Date | |
Msg-id | CA+hUKGJ2B5rAGUncAob=ChutCT=fx0Ot7kwvio5cB7NpOGKG1Q@mail.gmail.com Whole thread Raw |
In response to | Re: [PATCH] Add native windows on arm64 support (Andres Freund <andres@anarazel.de>) |
List | pgsql-hackers |
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
pgsql-hackers by date: