Add msvc support for AESCE

[yuhaoth]

Description

Fixes #6920

This PR is enable MSVC support for AESCE module.

The code is verified under below condition.

• Build with VS2022 and platformtoolsetversion=v143
  • With VS2022, platformtoolsetversion=v141 build fail. arm_neon.h reports ARM64 not supported
• Test on Windows 10 with selftest

NOTE: Build command msbuild /nodeReuse:false /t:Rebuild /p:Configuration=Debug,Platform=ARM64,PlatformToolset=v143 "mbedTLS.sln"

Gatekeeper checklist

• changelog not required - covered by Changelog and terminology tidy-up for AESCE #7313
• backport not in 2.28
• tests provided, or not required

[daverodgman]

AFAICT platformtoolsetversion=v141 means VS 2017. We support VS 2013 - so if this doesn't work on VS 2017, it needs to detect the compiler version and only enable for recent versions of VS.

[tom-cosgrove-arm]

With just this and the change to aesce.c, I get

Microsoft (R) Program Maintenance Utility Version 14.35.32215.0
Copyright (C) Microsoft Corporation.  All rights reserved.

        cl -nologo -Ilibrary/ -Iinclude/ -Fobuild\library\ -c ./library\aesce.c
aesce.c
./library\aesce.c(304): error C2440: 'type cast': cannot convert from '__n64' to 'poly64_t'
./library\aesce.c(301): error C2168: 'neon_pmull_64': too few actual parameters for intrinsic function
./library\aesce.c(368): error C2143: syntax error: missing ')' before ':'
NMAKE : fatal error U1077: 'cl -nologo -Ilibrary/ -Iinclude/ -Fobuild\library\ -c ./library\aesce.c' : return code '0x2'
Stop.

[tom-cosgrove-arm]

Would the project file changes fix that, do you think?

[tom-cosgrove-arm]

Hmm, looks like the type errors are related to https://developercommunity.visualstudio.com/t/arm64-wrong-and-missing-types-in-arm64-neonh/1590951

[yuhaoth]

I did not get this error. What's your build command. It looks like msvc 2022.

[tom-cosgrove-arm]

I was using a custom makefile. The command it executed was as shown

cl -nologo -Ilibrary/ -Iinclude/ -Fobuild\library\ -c ./library\aesce.c

The compiler it was running was

c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\bin\HostARM64\ARM64/cl.exe

i.e. Visual Studio 2022, running on ARM64, targeting ARM64

[yuhaoth]

let me try it.

I did not install arm64 host compiler. but I think it can be reproduced by same version.

[yuhaoth]

I can reproduce it now. I forget rebase this PR. :(

[tom-cosgrove-arm]

Note that uwp is a Windows Store build, and might not be targeted by everyone

[yuhaoth]

fixed.

[yuhaoth]

That might be a bug of GCC also.

GCC think poly64_t and poly64x1_t are different. So cast is a MUST for GCC. But I think they should be same, no cast needed

[tom-cosgrove-arm]

This probably also needs an update to check_config.h around where it says

#error "MBEDTLS_AESCE_C defined, but not all prerequisites"

[tom-cosgrove-arm]

There also needs to be a fix for around line 368 in aesce.h

/* use 'asm' as an optimisation barrier to prevent loading MODULO from memory */
asm ("" : "+w" (r));

[yuhaoth]

I just rebased this PR due to gcm compile fail.

[yuhaoth]

I have tried some msvc versions from vs2022 with bellow command

"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" x64_arm64 uwp 10.0.22621.0 -vcvars_ver=%1

cl -Ilibrary/ -Iinclude/ -c ./library\aesce.c

The versions are 14.16.27023 14.29.30133 14.30.30705 14.31.31103 14.32.31326 14.33.31629 14.34.3193314.35.32215

14.16.27023 reports ARM64 not support from arm_neon.h . Others passed above test.

[yuhaoth]

ARMCC reports license server error. Others pass

[yuhaoth]

Rebase to re-trigger CI

[yuhaoth]

It is replaced with #7286

[tom-cosgrove-arm]

Actually, could we not do that? i.e. let's not have one PR (7286) that does a bunch of completely different things.

There should be one PR to replace the Perl scripts with Python, and another to add MSVC support for AESCE

[yuhaoth]

Actually, could we not do that? i.e. let's not have one PR (7286) that does a bunch of completely different things.

There should be one PR to replace the Perl scripts with Python, and another to add MSVC support for AESCE

Agree. I do not think it more.

[daverodgman]

Do we want to add a #error if the user tries to build for Arm with MBEDTLS_AESCE_C enabled on an old MSVC? As it stands, I think it will silently not build AESCE_C, so if plain C is still enabled, the user will unexpectedly not get AESCE.

[daverodgman]

Looks good but the gcc check triggers when building with clang

[daverodgman]

I think the recommended way to detect gcc but not clang is defined(__GNUC__) && !defined(__clang__) - see https://github.com/abseil/abseil.github.io/blob/master/docs/cpp/platforms/macros.md

[tom-cosgrove-arm]

I think the recommended way to detect gcc but not clang is defined(__GNUC__) && !defined(__clang__) - see https://github.com/abseil/abseil.github.io/blob/master/docs/cpp/platforms/macros.md

That's what we normally do - but putting #if defined(__clang__) and #elif defined(__GNUC__) gives the same result

[daverodgman]

I think the recommended way to detect gcc but not clang is defined(__GNUC__) && !defined(__clang__) - see https://github.com/abseil/abseil.github.io/blob/master/docs/cpp/platforms/macros.md

That's what we normally do - but putting #if defined(__clang__) and #elif defined(__GNUC__) gives the same result

It would, but the first if condition also has a version check, so we do need the suggested fix.

[tom-cosgrove-arm]

LGTM