mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-10 01:48:00 +00:00
fca13a17b1
This applies to all of AES, SHA-1, SHA-256 and SHA-512. All those source files previously contained multiple implementations of the algorithm, enabled or disabled by ifdefs detecting whether they would work on a given compiler. And in order to get advanced machine instructions like AES-NI or NEON crypto into the output file when the compile flags hadn't enabled them, we had to do nasty stuff with compiler-specific pragmas or attributes. Now we can do the detection at cmake time, and enable advanced instructions in the more sensible way, by compile-time flags. So I've broken up each of these modules into lots of sub-pieces: a file called (e.g.) 'foo-common.c' containing common definitions across all implementations (such as round constants), one called 'foo-select.c' containing the top-level vtable(s), and a separate file for each implementation exporting just the vtable(s) for that implementation. One advantage of this is that it depends a lot less on compiler- specific bodgery. My particular least favourite part of the previous setup was the part where I had to _manually_ define some Arm ACLE feature macros before including <arm_neon.h>, so that it would define the intrinsics I wanted. Now I'm enabling interesting architecture features in the normal way, on the compiler command line, there's no need for that kind of trick: the right feature macros are already defined and <arm_neon.h> does the right thing. Another change in this reorganisation is that I've stopped assuming there's just one hardware implementation per platform. Previously, the accelerated vtables were called things like sha256_hw, and varied between FOO-NI and NEON depending on platform; and the selection code would simply ask 'is hw available? if so, use hw, else sw'. Now, each HW acceleration strategy names its vtable its own way, and the selection vtable has a whole list of possibilities to iterate over looking for a supported one. So if someone feels like writing a second accelerated implementation of something for a given platform - for example, I've heard you can use plain NEON to speed up AES somewhat even without the crypto extension - then it will now have somewhere to drop in alongside the existing ones.
51 lines
1.4 KiB
C
51 lines
1.4 KiB
C
#cmakedefine NO_IPV6
|
|
#cmakedefine NO_GSSAPI
|
|
#cmakedefine STATIC_GSSAPI
|
|
|
|
#cmakedefine NO_MULTIMON
|
|
|
|
#cmakedefine01 HAVE_WINRESRC_H
|
|
#cmakedefine01 HAVE_WINRES_H
|
|
#cmakedefine01 HAVE_WIN_H
|
|
#cmakedefine01 HAVE_NO_STDINT_H
|
|
#cmakedefine01 HAVE_GCP_RESULTSW
|
|
#cmakedefine01 HAVE_ADDDLLDIRECTORY
|
|
#cmakedefine01 HAVE_GETNAMEDPIPECLIENTPROCESSID
|
|
#cmakedefine01 HAVE_SETDEFAULTDLLDIRECTORIES
|
|
#cmakedefine01 HAVE_STRTOUMAX
|
|
|
|
#cmakedefine NOT_X_WINDOWS
|
|
|
|
#cmakedefine01 HAVE_ASM_HWCAP_H
|
|
#cmakedefine01 HAVE_SYS_AUXV_H
|
|
#cmakedefine01 HAVE_SYS_SYSCTL_H
|
|
#cmakedefine01 HAVE_SYS_TYPES_H
|
|
#cmakedefine01 HAVE_GLOB_H
|
|
#cmakedefine01 HAVE_FUTIMES
|
|
#cmakedefine01 HAVE_GETADDRINFO
|
|
#cmakedefine01 HAVE_POSIX_OPENPT
|
|
#cmakedefine01 HAVE_PTSNAME
|
|
#cmakedefine01 HAVE_SETRESUID
|
|
#cmakedefine01 HAVE_STRSIGNAL
|
|
#cmakedefine01 HAVE_UPDWTMPX
|
|
#cmakedefine01 HAVE_FSTATAT
|
|
#cmakedefine01 HAVE_DIRFD
|
|
#cmakedefine01 HAVE_SETPWENT
|
|
#cmakedefine01 HAVE_ENDPWENT
|
|
#cmakedefine01 HAVE_GETAUXVAL
|
|
#cmakedefine01 HAVE_ELF_AUX_INFO
|
|
#cmakedefine01 HAVE_SYSCTLBYNAME
|
|
#cmakedefine01 HAVE_CLOCK_MONOTONIC
|
|
#cmakedefine01 HAVE_CLOCK_GETTIME
|
|
#cmakedefine01 HAVE_SO_PEERCRED
|
|
#cmakedefine01 HAVE_PANGO_FONT_FAMILY_IS_MONOSPACE
|
|
#cmakedefine01 HAVE_PANGO_FONT_MAP_LIST_FAMILIES
|
|
|
|
#cmakedefine01 HAVE_AES_NI
|
|
#cmakedefine01 HAVE_SHA_NI
|
|
#cmakedefine01 HAVE_SHAINTRIN_H
|
|
#cmakedefine01 HAVE_NEON_CRYPTO
|
|
#cmakedefine01 HAVE_NEON_SHA512
|
|
#cmakedefine01 HAVE_NEON_SHA512_INTRINSICS
|
|
#cmakedefine01 USE_ARM64_NEON_H
|