`-Wasm-operand-widths` when building 4.2.0 for ARM64 Windows (+ ASM bignum seems broken)
Example:
-- The C compiler identification is Clang 21.1.4
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /home/appveyor/projects/curl-for-win/llvm-mingw/bin/clang
[...]
[107/508] Building C object crypto/CMakeFiles/crypto_obj.dir/bn/bn_add.c.obj
In file included from /home/appveyor/projects/curl-for-win/libressl/crypto/bn/bn_add.c:63:
/home/appveyor/projects/curl-for-win/libressl/crypto/bn/arch/aarch64/bn_arch.h:35:16: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
35 | : [n]"=r"(n)
| ^
/home/appveyor/projects/curl-for-win/libressl/crypto/bn/arch/aarch64/bn_arch.h:34:18: note: use constraint modifier "w"
34 | __asm__ ("clz %[n], %[w]"
| ^~~~
| %w[n]
/home/appveyor/projects/curl-for-win/libressl/crypto/bn/arch/aarch64/bn_arch.h:36:15: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
36 | : [w]"r"(w));
| ^
/home/appveyor/projects/curl-for-win/libressl/crypto/bn/arch/aarch64/bn_arch.h:34:24: note: use constraint modifier "w"
34 | __asm__ ("clz %[n], %[w]"
| ^~~~
| %w[w]
[...]
2365 of them appear in total.
Minimal reproducer with CMake:
cmake -B _bld \
-DBUILD_SHARED_LIBS=OFF -DLIBRESSL_APPS=OFF -DLIBRESSL_TESTS=OFF \
-DCMAKE_SYSTEM_NAME=Windows -DCMAKE_SYSTEM_PROCESSOR=aarch64 \
-DCMAKE_C_COMPILER_TARGET=aarch64-w64-mingw32 \
-DCMAKE_C_COMPILER=/path/to/llvm-mingw/bin/clang
The toolchain used is llvm-mingw: https://github.com/mstorsjo/llvm-mingw/releases/tag/20251021
Complete live log: https://ci.appveyor.com/project/curlorg/curl-for-win/builds/52968287 https://ci.appveyor.com/api/buildjobs/whw97v32kq69hj67/log
Full compiler command-line:
[112/508] /path/to/llvm-mingw/bin/clang --target=aarch64-w64-mingw32 -DHAVE_ASPRINTF
-DHAVE_FTRUNCATE -DHAVE_GETOPT -DHAVE_STRCASECMP -DHAVE_STRNLEN
-DLIBRESSL_CRYPTO_INTERNAL -DLIBRESSL_INTERNAL -DNO_SYSLOG
-DOPENSSLDIR=\"C:/Windows/libressl/ssl\" -DOPENSSL_NO_HW_PADLOCK
-DWIN32_LEAN_AND_MEAN -D_CRT_DEPRECATED_NO_WARNINGS -D_CRT_SECURE_NO_WARNINGS
-D_GNU_SOURCE -D_POSIX -D_POSIX_SOURCE -D_POSIX_THREAD_SAFE_FUNCTIONS
-D_REENTRANT -D_WIN32_WINNT=0x0600 -D__BEGIN_HIDDEN_DECLS=""
-D__END_HIDDEN_DECLS="" -D__USE_MINGW_ANSI_STDIO
-I/path/to/libressl-4.2.0/crypto/. -I/path/to/libressl-4.2.0/crypto/aes -I/path/to/libressl-4.2.0/crypto/asn1
-I/path/to/libressl-4.2.0/crypto/bio -I/path/to/libressl-4.2.0/crypto/bn -I/path/to/libressl-4.2.0/crypto/bytestring
-I/path/to/libressl-4.2.0/crypto/conf -I/path/to/libressl-4.2.0/crypto/dh -I/path/to/libressl-4.2.0/crypto/dsa
-I/path/to/libressl-4.2.0/crypto/curve25519 -I/path/to/libressl-4.2.0/crypto/ec -I/path/to/libressl-4.2.0/crypto/ecdh
-I/path/to/libressl-4.2.0/crypto/ecdsa -I/path/to/libressl-4.2.0/crypto/err -I/path/to/libressl-4.2.0/crypto/evp
-I/path/to/libressl-4.2.0/crypto/hidden -I/path/to/libressl-4.2.0/crypto/hmac -I/path/to/libressl-4.2.0/crypto/lhash
-I/path/to/libressl-4.2.0/crypto/mlkem -I/path/to/libressl-4.2.0/crypto/modes -I/path/to/libressl-4.2.0/crypto/ocsp
-I/path/to/libressl-4.2.0/crypto/pkcs12 -I/path/to/libressl-4.2.0/crypto/rsa -I/path/to/libressl-4.2.0/crypto/sha
-I/path/to/libressl-4.2.0/crypto/stack -I/path/to/libressl-4.2.0/crypto/x509 -I/path/to/libressl-4.2.0/crypto/../include/compat
-I/path/to/libressl-4.2.0/crypto/../include -I/path/to/libressl-4.2.0/_cm-bld-llvm-mingw-libressl-1210/include
-I/path/to/libressl-4.2.0/crypto/arch/aarch64 -I/path/to/libressl-4.2.0/crypto/bn/arch/aarch64
-Wall -O3 -Wno-pointer-sign -MD -MT crypto/CMakeFiles/crypto_obj.dir/bn/bn_add.c.obj
-MF crypto/CMakeFiles/crypto_obj.dir/bn/bn_add.c.obj.d -o crypto/CMakeFiles/crypto_obj.dir/bn/bn_add.c.obj
-c /path/to/libressl-4.2.0/crypto/bn/bn_add.c
The warnings were triggered by no longer disabling ASM for ARM64 on Windows since commit: 1df6b52b250f04cd322bf7a79e2105f9ed890802 #1177
[ Aside: llvm-mingw 21 (up to at least the current latest 21.1.4) broke curl Windows ARM64 LibreSSL builds (including 4.1.0, with and without ASM) for some reason. I'll need to investigate more. It makes curl crash with 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN) as soon as touching TLS. Seen with curl ARM64 Windows builds 8.15.0_6–8.16.0_12: https://curl.se/windows/. edit: OpenSSL is also broken with llvm-mingw 21. Disabling CFGuard -mguard=cf makes the crash disappear. edit 2: It turned out to be an llvm strip tool regression: https://github.com/curl/curl-for-win/commit/a5e6d0dcffa55a3da4ddd346c7ca77f05e455ece ]
Reverting to llvm-mingw 20.1.8: https://github.com/mstorsjo/llvm-mingw/releases/tag/20250709 allows testing this particular issue further.
The warnings seem to point to a valid issue, because with ASM enabled (the default), and thus using the ARM64 ASM bignum implementation (for which the warnings are shown), makes curl break with this error:
> curl.exe --disable -v -I https://curl.se/
Note: Using embedded CA bundle (227919 bytes)
Note: Using embedded CA bundle, for proxies (227919 bytes)
* Host openbsd.org:443 was resolved.
* IPv6: (none)
* IPv4: 199.185.178.80
* Trying 199.185.178.80:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* successfully imported CA certificate blob
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, decrypt error (563):
* TLS connect error: error:04FFF077:rsa routines:CRYPTO_internal:wrong signature length
* closing connection #0
curl: (35) TLS connect error: error:04FFF077:rsa routines:CRYPTO_internal:wrong signature length
Other websites, such as example.com seem to hang instead.
Rebuilding with -DENABLE_ASM=OFF makes the above command work as expected.
It'd be nicest to fix bignum for Windows ARM64. If that's not workable, disable ASM again, with:
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -412,6 +412,9 @@ endif()
if(CMAKE_SYSTEM_PROCESSOR MATCHES "(aarch64|arm64|ARM64)")
set(HOST_AARCH64 true)
+ if(WIN32)
+ set(ENABLE_ASM false)
+ endif()
elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "arm")
set(HOST_ARM true)
if(APPLE)
It would be interesting to try switching these to use ARM C intrinsics, which mostly work everywhere without much fuss or changes between platforms, based on my experiments last summer.
Already tagged 4.2.1, so will probably have to do a 4.2.2 for this.
It would be interesting to try switching these to use ARM C intrinsics, which mostly work everywhere without much fuss or changes between platforms, based on my experiments last summer.
Intrinsics are not going to help here - the real issue is that the BN configuration is pretty much broken for 64 bit Windows, which means we're using 32 bit BN_ULONGs and passing that into 64 bit assembly.