[PATCH] arm64: Use __builtin_ms_va_list and __attribute__((ms_abi)) on arm64

[André Hentschel]

Am 14.08.2017 um 12:35 schrieb Martin Storsjo:
> Windows uses a different ABI for va_list on arm64 just like on x86_64.
> 
> On x86_64, the calling convention for windows functions is completely
> different from the one on other platforms. On arm64, they're mostly the
> same, with the only exception being variadic functions (where all float
> arguments are passed in integer registers, since the va_list is a single
> pointer).
> 
> Any functions using __builtin_ms_va_start need to be decorated with
> __attribute__((ms_abi)).
> 
> Add a check in configure for the support of __builtin_ms_va_list
> (both features appared in clang at the same time, in the 5.0 release).
> 
> This fixes running binaries that use e.g. printf style functions
> (e.g. midl.exe from the windows 10 sdk), fixing
> https://bugs.winehq.org/show_bug.cgi?id=38886.
> 
> Signed-off-by: Martin Storsjo <martin at martin.st>
> ---
> clang 5.0, which this requires, isn't yet released, but is in RC2 and
> will probably be released pretty soon.
> ---
>  configure.ac             | 7 +++++++
>  include/msvcrt/crtdefs.h | 6 +++++-
>  include/windef.h         | 6 +++++-
>  include/wine/test.h      | 4 ++--
>  4 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 7d52b24..c33221f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -179,6 +179,13 @@ case $host in
>      CFLAGS="$CFLAGS -marm"
>      AC_SUBST(TARGETFLAGS,"-marm")
>      ;;
> +  aarch64*)
> +    AC_MSG_CHECKING([whether $CC supports __builtin_ms_va_list])
> +    AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <stdarg.h>]], [[void func(__builtin_ms_va_list *args);]])],
> +                      [AC_MSG_RESULT([yes])],
> +                      [AC_MSG_RESULT([no])
> +                       AC_MSG_ERROR([You need clang >= 5.0 to build Wine for arm64.])])

Hi,

The upstreamed variadic function handling is terrific, thanks for that!
I also like this patch as logical next step, I'm just a bit worried because it locks out current builds without upgrading to an RC...
At the moment I'm doing winelib builds with gcc for Linux/ARM64 and clang builds for Android/ARM64.
It's quite easy on Linux to pick up a new clang version, not sure how long it takes until clang5 is picked up in the Android NDK...
On the other hand, there are not much people building Wine for ARM64, and those can pretty easily revert your patch until they are at clang5
OK... We need this improvement, I'll sign it off :)

Now, we only need to convince distributions to avoid x18