Windows implementation of setjmp/longjmp is done in
C:/WINDOWS/system32/ucrtbase.dll. Alas, on arm64, it seems to *always*
perform stack unwinding, which crashes from generated code.

By using alternative implementation built in mingw, we avoid doing stack
unwinding and this fixes crash when calling longjmp.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
---
 include/sysemu/os-win32.h | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/sysemu/os-win32.h b/include/sysemu/os-win32.h
index 5b38c7bd04..84f62d0a17 100644
--- a/include/sysemu/os-win32.h
+++ b/include/sysemu/os-win32.h
@@ -51,14 +51,28 @@ typedef struct sockaddr_un {
 extern "C" {
 #endif
 
-#if defined(_WIN64)
+#if defined(__aarch64__)
+/* On windows-arm64, setjmp is available in only one variant, and longjmp always
+ * does stack unwinding. This crash with generated code.
+ * Thus, we use another implementation of setjmp (not windows one), coming from
+ * mingw, which never performs stack unwinding. */
+#undef setjmp
+#undef longjmp
+/* These functions are not declared in setjmp.h because __aarch64__ defines
+ * setjmp to _setjmpex instead. However, they are still defined in libmingwex.a,
+ * which gets linked automatically. */
+extern int __mingw_setjmp(jmp_buf);
+extern void __attribute__((noreturn)) __mingw_longjmp(jmp_buf, int);
+#define setjmp(env) __mingw_setjmp(env)
+#define longjmp(env, val) __mingw_longjmp(env, val)
+#elif defined(_WIN64)
 /* On w64, setjmp is implemented by _setjmp which needs a second parameter.
  * If this parameter is NULL, longjump does no stack unwinding.
  * That is what we need for QEMU. Passing the value of register rsp (default)
  * lets longjmp try a stack unwinding which will crash with generated code. */
 # undef setjmp
 # define setjmp(env) _setjmp(env, NULL)
-#endif
+#endif /* __aarch64__ */
 /* QEMU uses sigsetjmp()/siglongjmp() as the portable way to specify
  * "longjmp and don't touch the signal masks". Since we know that the
  * savemask parameter will always be zero we can safely define these
-- 
2.30.2

Hi Pierrick,

On 13/2/23 17:13, Pierrick Bouvier wrote:
> Windows implementation of setjmp/longjmp is done in
> C:/WINDOWS/system32/ucrtbase.dll. Alas, on arm64, it seems to *always*
> perform stack unwinding, which crashes from generated code.
> 
> By using alternative implementation built in mingw, we avoid doing stack
> unwinding and this fixes crash when calling longjmp.
> 
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> ---
>   include/sysemu/os-win32.h | 18 ++++++++++++++++--
>   1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/include/sysemu/os-win32.h b/include/sysemu/os-win32.h
> index 5b38c7bd04..84f62d0a17 100644
> --- a/include/sysemu/os-win32.h
> +++ b/include/sysemu/os-win32.h
> @@ -51,14 +51,28 @@ typedef struct sockaddr_un {
>   extern "C" {
>   #endif
>   
> -#if defined(_WIN64)
> +#if defined(__aarch64__)

Shouldn't we check for __MINGW64__?

    #if defined(__aarch64__) && defined(__MINGW64__)

> +/* On windows-arm64, setjmp is available in only one variant, and longjmp always
> + * does stack unwinding. This crash with generated code.
> + * Thus, we use another implementation of setjmp (not windows one), coming from
> + * mingw, which never performs stack unwinding. */
> +#undef setjmp
> +#undef longjmp
> +/* These functions are not declared in setjmp.h because __aarch64__ defines
> + * setjmp to _setjmpex instead. However, they are still defined in libmingwex.a,
> + * which gets linked automatically. */

So this is not stable. Better would be to check the symbols availability
at link-time via meson; see for example glusterfs_ftruncate_has_stat
which defines CONFIG_GLUSTERFS_FTRUNCATE_HAS_STAT.

A similar check could define CONFIG_MINGW64_HAS_SETJMP_LONGJMP.

> +extern int __mingw_setjmp(jmp_buf);
> +extern void __attribute__((noreturn)) __mingw_longjmp(jmp_buf, int);
> +#define setjmp(env) __mingw_setjmp(env)
> +#define longjmp(env, val) __mingw_longjmp(env, val)
> +#elif defined(_WIN64)
>   /* On w64, setjmp is implemented by _setjmp which needs a second parameter.
>    * If this parameter is NULL, longjump does no stack unwinding.
>    * That is what we need for QEMU. Passing the value of register rsp (default)
>    * lets longjmp try a stack unwinding which will crash with generated code. */
>   # undef setjmp
>   # define setjmp(env) _setjmp(env, NULL)
> -#endif
> +#endif /* __aarch64__ */
>   /* QEMU uses sigsetjmp()/siglongjmp() as the portable way to specify
>    * "longjmp and don't touch the signal masks". Since we know that the
>    * savemask parameter will always be zero we can safely define these

Regards,

Phil.

On 2/14/23 08:11, Philippe Mathieu-Daudé wrote:
> Hi Pierrick,
> 
> On 13/2/23 17:13, Pierrick Bouvier wrote:
>> Windows implementation of setjmp/longjmp is done in
>> C:/WINDOWS/system32/ucrtbase.dll. Alas, on arm64, it seems to *always*
>> perform stack unwinding, which crashes from generated code.
>>
>> By using alternative implementation built in mingw, we avoid doing stack
>> unwinding and this fixes crash when calling longjmp.
>>
>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>> ---
>>    include/sysemu/os-win32.h | 18 ++++++++++++++++--
>>    1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/sysemu/os-win32.h b/include/sysemu/os-win32.h
>> index 5b38c7bd04..84f62d0a17 100644
>> --- a/include/sysemu/os-win32.h
>> +++ b/include/sysemu/os-win32.h
>> @@ -51,14 +51,28 @@ typedef struct sockaddr_un {
>>    extern "C" {
>>    #endif
>>    
>> -#if defined(_WIN64)
>> +#if defined(__aarch64__)
> 
> Shouldn't we check for __MINGW64__?
> 
>      #if defined(__aarch64__) && defined(__MINGW64__)
>

I thought QEMU was only compiled using MinGW under Windows, (from CI, 
that's the case, [1], [2]), but maybe that's a wrong assumption.

[1] 
https://gitlab.com/qemu-project/qemu/-/blob/master/.gitlab-ci.d/windows.yml
[2] 
https://gitlab.com/qemu-project/qemu/-/blob/master/tests/docker/dockerfiles/fedora-win64-cross.docker

For windows-arm64, we need an alternative setjmp/longjmp implementation 
(__builtin_setjmp and __builtin_longjmp in clang are not available), 
thus, that makes MinGW mandatory, at least for this platform.

Would adding this be satisfying? Or better to add this check in Meson?
#ifndef __MINGW64__
#error MinGW must be available for this platform
#endif

>> +/* On windows-arm64, setjmp is available in only one variant, and longjmp always
>> + * does stack unwinding. This crash with generated code.
>> + * Thus, we use another implementation of setjmp (not windows one), coming from
>> + * mingw, which never performs stack unwinding. */
>> +#undef setjmp
>> +#undef longjmp
>> +/* These functions are not declared in setjmp.h because __aarch64__ defines
>> + * setjmp to _setjmpex instead. However, they are still defined in libmingwex.a,
>> + * which gets linked automatically. */
> 
> So this is not stable. Better would be to check the symbols availability
> at link-time via meson; see for example glusterfs_ftruncate_has_stat
> which defines CONFIG_GLUSTERFS_FTRUNCATE_HAS_STAT.
> 
> A similar check could define CONFIG_MINGW64_HAS_SETJMP_LONGJMP.
> 

You're right, it's not stable. Checking this using meson sounds a good 
approach.

>> +extern int __mingw_setjmp(jmp_buf);
>> +extern void __attribute__((noreturn)) __mingw_longjmp(jmp_buf, int);
>> +#define setjmp(env) __mingw_setjmp(env)
>> +#define longjmp(env, val) __mingw_longjmp(env, val)
>> +#elif defined(_WIN64)
>>    /* On w64, setjmp is implemented by _setjmp which needs a second parameter.
>>     * If this parameter is NULL, longjump does no stack unwinding.
>>     * That is what we need for QEMU. Passing the value of register rsp (default)
>>     * lets longjmp try a stack unwinding which will crash with generated code. */
>>    # undef setjmp
>>    # define setjmp(env) _setjmp(env, NULL)
>> -#endif
>> +#endif /* __aarch64__ */
>>    /* QEMU uses sigsetjmp()/siglongjmp() as the portable way to specify
>>     * "longjmp and don't touch the signal masks". Since we know that the
>>     * savemask parameter will always be zero we can safely define these
> 
> Regards,
> 
> Phil.