[v1,08/13] aarch64: Add Cygwin and MinGW environments for AArch64

From 1ea6efa6f88d131884ecef21c4b5d2ecbab14ea7 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 18:06:36 +0100
Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for
 AArch64

Define Cygwin and MinGW environment such as types, SEH definitions,
shared libraries, etc.

gcc/ChangeLog:

	* config.gcc: Add Cygwin and MinGW difinitions.
	* config/aarch64/aarch64-protos.h
	(mingw_pe_maybe_record_exported_symbol): Declare functions
	which are used in Cygwin and MinGW environment.
	(mingw_pe_section_type_flags): Likewise.
	(mingw_pe_unique_section): Likewise.
	(mingw_pe_encode_section_info): Likewise.
	* config/aarch64/cygming.h: New file.
---
 gcc/config.gcc                      |   1 +
 gcc/config/aarch64/aarch64-protos.h |   5 +
 gcc/config/aarch64/cygming.h        | 178 ++++++++++++++++++++++++++++
 3 files changed, 184 insertions(+)
 create mode 100644 gcc/config/aarch64/cygming.h

On 21/02/2024 18:36, Evgeny Karpov wrote:
> 
+/* GNU as supports weak symbols on PECOFF.  */
+#ifdef HAVE_GAS_WEAK

Can't we assume this is true?  It was most likely needed on i386 because support goes back longer than the assembler had this feature, but it looks like it was added in 2000, or thereabouts, so significantly before aarch64 was supported in the assembler.

+#ifndef HAVE_GAS_ALIGNED_COMM

And this was added to GCC in 2009, which probably means it predates aarch64-coff support in gas as well.

R.

Evgeny Karpov <Evgeny.Karpov@microsoft.com> writes:
> From 1ea6efa6f88d131884ecef21c4b5d2ecbab14ea7 Mon Sep 17 00:00:00 2001
> From: Zac Walker <zacwalker@microsoft.com>
> Date: Tue, 20 Feb 2024 18:06:36 +0100
> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for
>  AArch64
>
> Define Cygwin and MinGW environment such as types, SEH definitions,
> shared libraries, etc.
>
> gcc/ChangeLog:
>
> 	* config.gcc: Add Cygwin and MinGW difinitions.
> 	* config/aarch64/aarch64-protos.h
> 	(mingw_pe_maybe_record_exported_symbol): Declare functions
> 	which are used in Cygwin and MinGW environment.
> 	(mingw_pe_section_type_flags): Likewise.
> 	(mingw_pe_unique_section): Likewise.
> 	(mingw_pe_encode_section_info): Likewise.
> 	* config/aarch64/cygming.h: New file.
> ---
>  gcc/config.gcc                      |   1 +
>  gcc/config/aarch64/aarch64-protos.h |   5 +
>  gcc/config/aarch64/cygming.h        | 178 ++++++++++++++++++++++++++++
>  3 files changed, 184 insertions(+)
>  create mode 100644 gcc/config/aarch64/cygming.h
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 498ee702607..96e3508eb30 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1265,6 +1265,7 @@ aarch64*-*-linux*)
>  	;;
>  aarch64*-*-mingw*)
>  	tm_file="${tm_file} aarch64/aarch64-coff.h"
> +	tm_file="${tm_file} aarch64/cygming.h"
>  	tm_file="${tm_file} mingw/mingw32.h"
>  	tm_file="${tm_file} mingw/mingw-stdint.h"
>  	tmake_file="${tmake_file} aarch64/t-aarch64"
> diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
> index a0b142e0b94..6d85452b0f6 100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -1109,6 +1109,11 @@ extern void aarch64_output_patchable_area (unsigned int, bool);
>  
>  extern void aarch64_adjust_reg_alloc_order ();
>  
> +extern void mingw_pe_maybe_record_exported_symbol (tree, const char *, int);
> +extern unsigned int mingw_pe_section_type_flags (tree, const char *, int);
> +extern void mingw_pe_unique_section (tree, int);
> +extern void mingw_pe_encode_section_info (tree, rtx, int);
> +
>  bool aarch64_optimize_mode_switching (aarch64_mode_entity);
>  void aarch64_restore_za (rtx);
>  
> diff --git a/gcc/config/aarch64/cygming.h b/gcc/config/aarch64/cygming.h
> new file mode 100644
> index 00000000000..cf47184eb66
> --- /dev/null
> +++ b/gcc/config/aarch64/cygming.h
> @@ -0,0 +1,178 @@
> +/* Operating system specific defines to be used when targeting GCC for
> +   hosting on Windows32, using a Unix style C library and tools.
> +   Copyright (C) 1995-2024 Free Software Foundation, Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with GCC; see the file COPYING3.  If not see
> +<http://www.gnu.org/licenses/>.  */
> +
> +#ifndef GCC_AARCH64_CYGMING_H
> +#define GCC_AARCH64_CYGMING_H
> +
> +#undef PREFERRED_DEBUGGING_TYPE
> +#define PREFERRED_DEBUGGING_TYPE DINFO_TYPE_NONE
> +
> +#define FASTCALL_PREFIX '@'
> +
> +#define print_reg(rtx, code, file)
> +
> +#define SYMBOL_FLAG_DLLIMPORT 0
> +#define SYMBOL_FLAG_DLLEXPORT 0
> +
> +#define SYMBOL_REF_DLLEXPORT_P(X) \
> +	((SYMBOL_REF_FLAGS (X) & SYMBOL_FLAG_DLLEXPORT) != 0)
> +
> +#undef TARGET_SEH
> +#define TARGET_SEH 0
> +
> +#define SSE_REGNO_P(N) 0
> +#define GENERAL_REGNO_P(N) 0

Could you add a comment to explain how these two macros are consumed?
What is the effect of saying that everything is neither a general
register nor an SSE register?

> +#define SEH_MAX_FRAME_SIZE 0
> +
> +#undef DEFAULT_ABI
> +#define DEFAULT_ABI MS_ABI
> +
> +#undef TARGET_PECOFF
> +#define TARGET_PECOFF 1
> +
> +#include <stdbool.h>
> +#ifdef __MINGW32__
> +#include <stdio.h>
> +#endif
> +
> +extern void mingw_pe_asm_named_section (const char *, unsigned int, tree);
> +extern void mingw_pe_declare_function_type (FILE *file, const char *name,
> +	int pub);
> +
> +#define TARGET_ASM_NAMED_SECTION  mingw_pe_asm_named_section
> +
> +/* Select attributes for named sections.  */
> +#define TARGET_SECTION_TYPE_FLAGS  mingw_pe_section_type_flags
> +
> +#define TARGET_ASM_UNIQUE_SECTION mingw_pe_unique_section
> +#define TARGET_ENCODE_SECTION_INFO  mingw_pe_encode_section_info
> +
> +/* Declare the type properly for any external libcall.  */
> +#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \
> +  mingw_pe_declare_function_type (FILE, XSTR (FUN, 0), 1)
> +
> +#define TARGET_OS_CPP_BUILTINS()					\
> +  do									\
> +    {									\
> +      builtin_define ("__MSVCRT__");					\
> +      builtin_define ("__MINGW32__");					\
> +      builtin_define ("_WIN32");					\
> +      builtin_define_std ("WIN32");					\
> +      builtin_define_std ("WINNT");					\
> +      builtin_define_with_int_value ("_INTEGRAL_MAX_BITS",		\
> +				TYPE_PRECISION (intmax_type_node));	\
> +      builtin_define ("__MINGW64__");					\
> +      builtin_define_std ("WIN64");					\
> +      builtin_define ("_WIN64");					\
> +      builtin_define ("__stdcall=__attribute__((__stdcall__))");	\
> +      builtin_define ("__fastcall=__attribute__((__fastcall__))");	\
> +      builtin_define ("__thiscall=__attribute__((__thiscall__))");	\
> +      builtin_define ("__cdecl=__attribute__((__cdecl__))");		\
> +    }									\
> +  while (0)
> +
> +/* Windows64 continues to use a 32-bit long type.  */
> +#undef LONG_TYPE_SIZE
> +#define LONG_TYPE_SIZE 32

Just curious: this is AFAIK the first IL32P64 ABI for AArch64.
Do things Just Work, including for things like arm_neon.h and
other ACLE header files?  I'm pleasantly surprised if so :)

> +
> +#undef DEFAULT_SIGNED_CHAR
> +#define DEFAULT_SIGNED_CHAR 1
> +
> +#undef SIZE_TYPE
> +#undef PTRDIFF_TYPE
> +#define SIZE_TYPE "long long unsigned int"
> +#define PTRDIFF_TYPE "long long int"
> +
> +#undef WCHAR_TYPE_SIZE
> +#undef WCHAR_TYPE
> +#define WCHAR_TYPE_SIZE 16
> +#define WCHAR_TYPE "short unsigned int"
> +
> +#define drectve_section() \
> +  (fprintf (asm_out_file, "\t.section\t.drectve\n"), \
> +   in_section = NULL)
> +
> +
> +/* Enable alias attribute support.  */
> +#ifndef SET_ASM_OP
> +#define SET_ASM_OP "\t.set\t"
> +#endif
> +
> +/* GNU as supports weak symbols on PECOFF.  */
> +#ifdef HAVE_GAS_WEAK
> +#define ASM_WEAKEN_LABEL(FILE, NAME)	\
> +  do					\
> +    {					\
> +      fputs ("\t.weak\t", (FILE));	\
> +      assemble_name ((FILE), (NAME));	\
> +      fputc ('\n', (FILE));		\
> +    }					\
> +  while (0)
> +
> +#endif /* HAVE_GAS_WEAK.  */
> +
> +/* Get tree.cc to declare a target-specific specialization of
> +   merge_decl_attributes.  */
> +#define TARGET_DLLIMPORT_DECL_ATTRIBUTES 1
> +
> +#define ASM_OUTPUT_ADDR_DIFF_ELT(STREAM, BODY, VALUE, REL)		\
> +  do {									\
> +    switch (GET_MODE (BODY))						\
> +      {									\
> +      case E_QImode:							\
> +	asm_fprintf (STREAM, "\t.byte\t(%LL%d - %LLrtx%d) / 4\n",	\
> +		     VALUE, REL);					\
> +	break;								\
> +      case E_HImode:							\
> +	asm_fprintf (STREAM, "\t.2byte\t(%LL%d - %LLrtx%d) / 4\n",	\
> +		     VALUE, REL);					\
> +	break;								\
> +      case E_SImode:							\
> +      case E_DImode: /* See comment in aarch64_output_casesi.  */	\
> +	asm_fprintf (STREAM, "\t.word\t(%LL%d - %LLrtx%d) / 4\n",	\
> +		     VALUE, REL);					\
> +	break;								\
> +      default:								\
> +	gcc_unreachable ();						\
> +      }									\
> +  } while (0)
> +
> +#define READONLY_DATA_SECTION_ASM_OP "\t.section\t.rdata,\"dr\""
> +
> +#undef  SUBTARGET_OVERRIDE_OPTIONS
> +#define SUBTARGET_OVERRIDE_OPTIONS			\
> +  do {							\
> +    flag_stack_check = STATIC_BUILTIN_STACK_CHECK;	\

I suppose this is more of a generic mingw/cygwin question, but does
this mean that stack checking cannot be explicitly disabled by a
user who "knows what they are doing"?

Thanks,
Richard

> +  } while (0)
> +
> +
> +#define SUPPORTS_ONE_ONLY 1
> +
> +/* Define this to be nonzero if static stack checking is supported.  */
> +#define STACK_CHECK_STATIC_BUILTIN 1
> +
> +#ifndef HAVE_GAS_ALIGNED_COMM
> +# define HAVE_GAS_ALIGNED_COMM 0
> +#endif
> +
> +#undef MAX_OFILE_ALIGNMENT
> +#define MAX_OFILE_ALIGNMENT (8192 * 8)
> +
> +#endif

Thank you for the historical information regarding the introduction 
of the features. I can confirm that removing the HAVE_GAS_WEAK check
and setting HAVE_GAS_ALIGNED_COMM to 1 by default works well.
These changes will be included in v2.

Regards,
Evgeny


-----Original Message-----
Thursday, February 22, 2024 2:23 PM
Richard Earnshaw (lists) wrote:

>
+/* GNU as supports weak symbols on PECOFF.  */ #ifdef HAVE_GAS_WEAK

Can't we assume this is true?  It was most likely needed on i386 because support goes back longer than the assembler had this feature, but it looks like it was added in 2000, or thereabouts, so significantly before aarch64 was supported in the assembler.

+#ifndef HAVE_GAS_ALIGNED_COMM

And this was added to GCC in 2009, which probably means it predates aarch64-coff support in gas as well.

R.

SEH is not implemented yet and needs to be disabled in mingw/winnt.cc. Disabling every SEH function that uses references to these macros might trigger significant refactoring, and to avoid this, required macros are defined with 0. It is needed only for compilation. A comment with an explanation will be added.

It looks like IL32P64 works. It has been tested on OpenSSL, OpenBLAS, libjpeg-turbo, and FFmpeg packages. No issues have been detected with it.

Correct, stack checking cannot be explicitly disabled by the user. It will be interesting to know cases when it is needed. GCC uses stack probing only when the stack size is exceeded; size optimization is not an option then.

Regards,
Evgeny


-----Original Message-----
Friday, February 23, 2024 6:16 PM 
Richard Sandiford wrote:
 
> +
> +#undef TARGET_SEH
> +#define TARGET_SEH 0
> +
> +#define SSE_REGNO_P(N) 0
> +#define GENERAL_REGNO_P(N) 0

Could you add a comment to explain how these two macros are consumed?
What is the effect of saying that everything is neither a general register nor an SSE register?

> +#define SEH_MAX_FRAME_SIZE 0


> +/* Windows64 continues to use a 32-bit long type.  */ #undef 
> +LONG_TYPE_SIZE #define LONG_TYPE_SIZE 32

Just curious: this is AFAIK the first IL32P64 ABI for AArch64.
Do things Just Work, including for things like arm_neon.h and other ACLE header files?  I'm pleasantly surprised if so :)

I suppose this is more of a generic mingw/cygwin question, but does this mean that stack checking cannot be explicitly disabled by a user who "knows what they are doing"?

Thanks,
Richard

On Tue, Feb 27, 2024 at 1:18 PM Evgeny Karpov
<Evgeny.Karpov@microsoft.com> wrote:
>
> SEH is not implemented yet and needs to be disabled in mingw/winnt.cc. Disabling every SEH function that uses references to these macros might trigger significant refactoring, and to avoid this, required macros are defined with 0. It is needed only for compilation. A comment with an explanation will be added.

What does this mean with respect to C++ exceptions? Or you using SJLJ
exceptions support or the dwarf unwinding ones without SEH support?
I am not sure if SJLJ exceptions is well tested any more in GCC either.

Also I have a question if you ran the full GCC/G++ testsuites and what
were the results?
If you did run it, did you use a cross compiler or the native
compiler? Did you do a bootstrap (GCC uses C++ but no exceptions
though)?
If you run using a cross compiler, did you use ssh or some other route
to run the applications?

Thanks,
Andrew Pinski

>
> It looks like IL32P64 works. It has been tested on OpenSSL, OpenBLAS, libjpeg-turbo, and FFmpeg packages. No issues have been detected with it.
>
> Correct, stack checking cannot be explicitly disabled by the user. It will be interesting to know cases when it is needed. GCC uses stack probing only when the stack size is exceeded; size optimization is not an option then.
>
> Regards,
> Evgeny
>
>
> -----Original Message-----
> Friday, February 23, 2024 6:16 PM
> Richard Sandiford wrote:
>
> > +
> > +#undef TARGET_SEH
> > +#define TARGET_SEH 0
> > +
> > +#define SSE_REGNO_P(N) 0
> > +#define GENERAL_REGNO_P(N) 0
>
> Could you add a comment to explain how these two macros are consumed?
> What is the effect of saying that everything is neither a general register nor an SSE register?
>
> > +#define SEH_MAX_FRAME_SIZE 0
>
>
> > +/* Windows64 continues to use a 32-bit long type.  */ #undef
> > +LONG_TYPE_SIZE #define LONG_TYPE_SIZE 32
>
> Just curious: this is AFAIK the first IL32P64 ABI for AArch64.
> Do things Just Work, including for things like arm_neon.h and other ACLE header files?  I'm pleasantly surprised if so :)
>
> I suppose this is more of a generic mingw/cygwin question, but does this mean that stack checking cannot be explicitly disabled by a user who "knows what they are doing"?
>
> Thanks,
> Richard
>

> -----Original Message-----
> Friday, February 23, 2024 6:16 PM
> Richard Sandiford wrote:
>
> > +
> > +#undef TARGET_SEH
> > +#define TARGET_SEH 0
> > +
> > +#define SSE_REGNO_P(N) 0
> > +#define GENERAL_REGNO_P(N) 0
>
> Could you add a comment to explain how these two macros are consumed?
> What is the effect of saying that everything is neither a general register nor an SSE register?
>
> > +#define SEH_MAX_FRAME_SIZE 0

On Tue, Feb 27, 2024 at 4:17 PM Evgeny Karpov
<Evgeny.Karpov@microsoft.com> wrote:
>
> SEH is not implemented yet and needs to be disabled in mingw/winnt.cc. Disabling every SEH function that uses references to these macros might trigger significant refactoring, and to avoid this, required macros are defined with 0. It is needed only for compilation. A comment with an explanation will be added.

This is all the more reason why you need to show the full testsuite
run for x86/x64 mingw as per my previous message.  We do use SEH by
default on x64.

Also, this is a friendly reminder that the GCC list is a bottom
posting list, not top posting, which is the default for your email
client.  I fixed this email for you.

Wednesday, February 28, 2024 2:00 AM
Andrew Pinski wrote:

> What does this mean with respect to C++ exceptions? Or you using SJLJ
> exceptions support or the dwarf unwinding ones without SEH support?
> I am not sure if SJLJ exceptions is well tested any more in GCC either.
> 
> Also I have a question if you ran the full GCC/G++ testsuites and what were the
> results?
> If you did run it, did you use a cross compiler or the native compiler? Did you
> do a bootstrap (GCC uses C++ but no exceptions though)?

As mentioned in the cover letter and the thread, the current
contribution covers only the C scope.
Exception handling is fully disabled for now.
There is an experimental build with C++ and SEH, however, it
is not included in the plan for the current contribution.

https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build

> If you run using a cross compiler, did you use ssh or some other route to run
> the applications?
> 
> Thanks,
> Andrew Pinski

GitHub Actions are used to cross-compile toolchains, packages
and tests, and execute tests on Windows Arm64.

https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/actions/runs/7929205044

Regards,
Evgeny

> -----Original Message-----
> From: Evgeny Karpov <Evgeny.Karpov@microsoft.com>
> Sent: Thursday, February 29, 2024 8:46 AM
> To: Andrew Pinski <pinskia@gmail.com>
> Cc: Richard Sandiford <richard.sandiford@arm.com>; gcc-
> patches@gcc.gnu.org; 10walls@gmail.com; Maxim Kuvyrkov
> <maxim.kuvyrkov@linaro.org>; mark@harmstone.com; Zac Walker
> <zacwalker@microsoft.com>; Ron Riddle <Ron.Riddle@microsoft.com>; Radek
> Barton <radek.barton@microsoft.com>; Andrew Pinski (QUIC)
> <quic_apinski@quicinc.com>
> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments
> for AArch64
> 
> Wednesday, February 28, 2024 2:00 AM
> Andrew Pinski wrote:
> 
> > What does this mean with respect to C++ exceptions? Or you using SJLJ
> > exceptions support or the dwarf unwinding ones without SEH support?
> > I am not sure if SJLJ exceptions is well tested any more in GCC either.
> >
> > Also I have a question if you ran the full GCC/G++ testsuites and what
> > were the results?
> > If you did run it, did you use a cross compiler or the native
> > compiler? Did you do a bootstrap (GCC uses C++ but no exceptions though)?
> 
> As mentioned in the cover letter and the thread, the current contribution
> covers only the C scope.
> Exception handling is fully disabled for now.
> There is an experimental build with C++ and SEH, however, it is not included in
> the plan for the current contribution.
> 
> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build
> 
> > If you run using a cross compiler, did you use ssh or some other route
> > to run the applications?
> >
> > Thanks,
> > Andrew Pinski
> 
> GitHub Actions are used to cross-compile toolchains, packages and tests, and
> execute tests on Windows Arm64.

This does not answer my question because what you are running is just simple testcases and not the FULL GCC testsuite.
So again have you ran the GCC testsuite and do you have a dejagnu board to be able to execute the binaries?
I think without the GCC testsuite ran to find all of the known failures, you are going to be running into many issues.
The GCC testsuite includes many tests for ABI corner cases and many features that you will most likely not think about testing using your simple testcases.
In fact I suspect there will be some of the aarch64 testcases which will need to be modified for the windows ABI which you have not done yet.


Thanks,
Andrew Pinski

> 
> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-
> build/actions/runs/7929205044
> 
> Regards,
> Evgeny

> On Feb 29, 2024, at 21:35, Andrew Pinski (QUIC) <quic_apinski@quicinc.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Evgeny Karpov <Evgeny.Karpov@microsoft.com>
>> Sent: Thursday, February 29, 2024 8:46 AM
>> To: Andrew Pinski <pinskia@gmail.com>
>> Cc: Richard Sandiford <richard.sandiford@arm.com>; gcc-
>> patches@gcc.gnu.org; 10walls@gmail.com; Maxim Kuvyrkov
>> <maxim.kuvyrkov@linaro.org>; mark@harmstone.com; Zac Walker
>> <zacwalker@microsoft.com>; Ron Riddle <Ron.Riddle@microsoft.com>; Radek
>> Barton <radek.barton@microsoft.com>; Andrew Pinski (QUIC)
>> <quic_apinski@quicinc.com>
>> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments
>> for AArch64
>> 
>> Wednesday, February 28, 2024 2:00 AM
>> Andrew Pinski wrote:
>> 
>>> What does this mean with respect to C++ exceptions? Or you using SJLJ
>>> exceptions support or the dwarf unwinding ones without SEH support?
>>> I am not sure if SJLJ exceptions is well tested any more in GCC either.
>>> 
>>> Also I have a question if you ran the full GCC/G++ testsuites and what
>>> were the results?
>>> If you did run it, did you use a cross compiler or the native
>>> compiler? Did you do a bootstrap (GCC uses C++ but no exceptions though)?
>> 
>> As mentioned in the cover letter and the thread, the current contribution
>> covers only the C scope.
>> Exception handling is fully disabled for now.
>> There is an experimental build with C++ and SEH, however, it is not included in
>> the plan for the current contribution.
>> 
>> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build
>> 
>>> If you run using a cross compiler, did you use ssh or some other route
>>> to run the applications?
>>> 
>>> Thanks,
>>> Andrew Pinski
>> 
>> GitHub Actions are used to cross-compile toolchains, packages and tests, and
>> execute tests on Windows Arm64.
> 
> This does not answer my question because what you are running is just simple testcases and not the FULL GCC testsuite.
> So again have you ran the GCC testsuite and do you have a dejagnu board to be able to execute the binaries?
> I think without the GCC testsuite ran to find all of the known failures, you are going to be running into many issues.
> The GCC testsuite includes many tests for ABI corner cases and many features that you will most likely not think about testing using your simple testcases.
> In fact I suspect there will be some of the aarch64 testcases which will need to be modified for the windows ABI which you have not done yet.

Hi Andrew,

We (Linaro) have a prototype CI loop setup for testing aarch64-w64-mingw32, and we have results for gcc-c and libatomic -- see [1].

The results are far from clean, but that's expected.  This patch series aims at enabling C hello-world only, and subsequent patch series will improve the state of the port.

[1] https://ci.linaro.org/job/tcwg_gnu_mingw_check_gcc--master-woa64-build/6/artifact/artifacts/sumfiles/

Thanks,

--
Maxim Kuvyrkov
https://www.linaro.org

> -----Original Message-----
> From: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
> Sent: Thursday, February 29, 2024 9:46 AM
> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
> Cc: Evgeny Karpov <Evgeny.Karpov@microsoft.com>; Andrew Pinski
> <pinskia@gmail.com>; Richard Sandiford <richard.sandiford@arm.com>; gcc-
> patches@gcc.gnu.org; 10walls@gmail.com; mark@harmstone.com; Zac
> Walker <zacwalker@microsoft.com>; Ron Riddle
> <Ron.Riddle@microsoft.com>; Radek Barton <radek.barton@microsoft.com>
> Subject: Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW
> environments for AArch64
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> > On Feb 29, 2024, at 21:35, Andrew Pinski (QUIC)
> <quic_apinski@quicinc.com> wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: Evgeny Karpov <Evgeny.Karpov@microsoft.com>
> >> Sent: Thursday, February 29, 2024 8:46 AM
> >> To: Andrew Pinski <pinskia@gmail.com>
> >> Cc: Richard Sandiford <richard.sandiford@arm.com>; gcc-
> >> patches@gcc.gnu.org; 10walls@gmail.com; Maxim Kuvyrkov
> >> <maxim.kuvyrkov@linaro.org>; mark@harmstone.com; Zac Walker
> >> <zacwalker@microsoft.com>; Ron Riddle <Ron.Riddle@microsoft.com>;
> >> Radek Barton <radek.barton@microsoft.com>; Andrew Pinski (QUIC)
> >> <quic_apinski@quicinc.com>
> >> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments
> >> for AArch64
> >>
> >> Wednesday, February 28, 2024 2:00 AM
> >> Andrew Pinski wrote:
> >>
> >>> What does this mean with respect to C++ exceptions? Or you using
> >>> SJLJ exceptions support or the dwarf unwinding ones without SEH
> support?
> >>> I am not sure if SJLJ exceptions is well tested any more in GCC either.
> >>>
> >>> Also I have a question if you ran the full GCC/G++ testsuites and
> >>> what were the results?
> >>> If you did run it, did you use a cross compiler or the native
> >>> compiler? Did you do a bootstrap (GCC uses C++ but no exceptions
> though)?
> >>
> >> As mentioned in the cover letter and the thread, the current
> >> contribution covers only the C scope.
> >> Exception handling is fully disabled for now.
> >> There is an experimental build with C++ and SEH, however, it is not
> >> included in the plan for the current contribution.
> >>
> >> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-
> build
> >>
> >>> If you run using a cross compiler, did you use ssh or some other
> >>> route to run the applications?
> >>>
> >>> Thanks,
> >>> Andrew Pinski
> >>
> >> GitHub Actions are used to cross-compile toolchains, packages and
> >> tests, and execute tests on Windows Arm64.
> >
> > This does not answer my question because what you are running is just
> simple testcases and not the FULL GCC testsuite.
> > So again have you ran the GCC testsuite and do you have a dejagnu board to
> be able to execute the binaries?
> > I think without the GCC testsuite ran to find all of the known failures, you are
> going to be running into many issues.
> > The GCC testsuite includes many tests for ABI corner cases and many
> features that you will most likely not think about testing using your simple
> testcases.
> > In fact I suspect there will be some of the aarch64 testcases which will need
> to be modified for the windows ABI which you have not done yet.
> 
> Hi Andrew,
> 
> We (Linaro) have a prototype CI loop setup for testing aarch64-w64-
> mingw32, and we have results for gcc-c and libatomic -- see [1].
> 
> The results are far from clean, but that's expected.  This patch series aims at
> enabling C hello-world only, and subsequent patch series will improve the
> state of the port.
> 
> [1] https://ci.linaro.org/job/tcwg_gnu_mingw_check_gcc--master-woa64-
> build/6/artifact/artifacts/sumfiles/

Looking at these results, this port is not in any shape or form to be upstreamed right now. Even simple -g will cause failures.
Note we don't need a clean testsuite run but the patch series is not even allowing enabling hello world due to the -g not being able to used.

Thanks,
Amdrew Pinski

> 
> Thanks,
> 
> --
> Maxim Kuvyrkov
> https://www.linaro.org

On 29/02/2024 17:55, Andrew Pinski (QUIC) wrote:
>> -----Original Message-----
>> From: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
>> Sent: Thursday, February 29, 2024 9:46 AM
>> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
>> Cc: Evgeny Karpov <Evgeny.Karpov@microsoft.com>; Andrew Pinski
>> <pinskia@gmail.com>; Richard Sandiford <richard.sandiford@arm.com>; gcc-
>> patches@gcc.gnu.org; 10walls@gmail.com; mark@harmstone.com; Zac
>> Walker <zacwalker@microsoft.com>; Ron Riddle
>> <Ron.Riddle@microsoft.com>; Radek Barton <radek.barton@microsoft.com>
>> Subject: Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW
>> environments for AArch64
>>
>> WARNING: This email originated from outside of Qualcomm. Please be wary
>> of any links or attachments, and do not enable macros.
>>
>>> On Feb 29, 2024, at 21:35, Andrew Pinski (QUIC)
>> <quic_apinski@quicinc.com> wrote:
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Evgeny Karpov <Evgeny.Karpov@microsoft.com>
>>>> Sent: Thursday, February 29, 2024 8:46 AM
>>>> To: Andrew Pinski <pinskia@gmail.com>
>>>> Cc: Richard Sandiford <richard.sandiford@arm.com>; gcc-
>>>> patches@gcc.gnu.org; 10walls@gmail.com; Maxim Kuvyrkov
>>>> <maxim.kuvyrkov@linaro.org>; mark@harmstone.com; Zac Walker
>>>> <zacwalker@microsoft.com>; Ron Riddle <Ron.Riddle@microsoft.com>;
>>>> Radek Barton <radek.barton@microsoft.com>; Andrew Pinski (QUIC)
>>>> <quic_apinski@quicinc.com>
>>>> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments
>>>> for AArch64
>>>>
>>>> Wednesday, February 28, 2024 2:00 AM
>>>> Andrew Pinski wrote:
>>>>
>>>>> What does this mean with respect to C++ exceptions? Or you using
>>>>> SJLJ exceptions support or the dwarf unwinding ones without SEH
>> support?
>>>>> I am not sure if SJLJ exceptions is well tested any more in GCC either.
>>>>>
>>>>> Also I have a question if you ran the full GCC/G++ testsuites and
>>>>> what were the results?
>>>>> If you did run it, did you use a cross compiler or the native
>>>>> compiler? Did you do a bootstrap (GCC uses C++ but no exceptions
>> though)?
>>>>
>>>> As mentioned in the cover letter and the thread, the current
>>>> contribution covers only the C scope.
>>>> Exception handling is fully disabled for now.
>>>> There is an experimental build with C++ and SEH, however, it is not
>>>> included in the plan for the current contribution.
>>>>
>>>> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-
>> build
>>>>
>>>>> If you run using a cross compiler, did you use ssh or some other
>>>>> route to run the applications?
>>>>>
>>>>> Thanks,
>>>>> Andrew Pinski
>>>>
>>>> GitHub Actions are used to cross-compile toolchains, packages and
>>>> tests, and execute tests on Windows Arm64.
>>>
>>> This does not answer my question because what you are running is just
>> simple testcases and not the FULL GCC testsuite.
>>> So again have you ran the GCC testsuite and do you have a dejagnu board to
>> be able to execute the binaries?
>>> I think without the GCC testsuite ran to find all of the known failures, you are
>> going to be running into many issues.
>>> The GCC testsuite includes many tests for ABI corner cases and many
>> features that you will most likely not think about testing using your simple
>> testcases.
>>> In fact I suspect there will be some of the aarch64 testcases which will need
>> to be modified for the windows ABI which you have not done yet.
>>
>> Hi Andrew,
>>
>> We (Linaro) have a prototype CI loop setup for testing aarch64-w64-
>> mingw32, and we have results for gcc-c and libatomic -- see [1].
>>
>> The results are far from clean, but that's expected.  This patch series aims at
>> enabling C hello-world only, and subsequent patch series will improve the
>> state of the port.
>>
>> [1] https://ci.linaro.org/job/tcwg_gnu_mingw_check_gcc--master-woa64-
>> build/6/artifact/artifacts/sumfiles/
> 
> Looking at these results, this port is not in any shape or form to be upstreamed right now. Even simple -g will cause failures.
> Note we don't need a clean testsuite run but the patch series is not even allowing enabling hello world due to the -g not being able to used.
> 

It seemed to me as though the patch was posted for comments, not for immediate inclusion.  I agree this isn't ready for committing yet, but neither should the submitters wait until it's perfect before posting it.

I think it's gcc-15 material, so now is about the right time to be thinking about it.

R.

> Thanks,
> Amdrew Pinski
> 
>>
>> Thanks,
>>
>> --
>> Maxim Kuvyrkov
>> https://www.linaro.org
>

Thursday, February 29, 2024 6:56 PM
Andrew Pinski (QUIC) wrote:

> Looking at these results, this port is not in any shape or form to be upstreamed
> right now. Even simple -g will cause failures.
> Note we don't need a clean testsuite run but the patch series is not even
> allowing enabling hello world due to the -g not being able to used.
> 
> Thanks,
> Amdrew Pinski

For now, our contribution plan contains 4 patch series.

1. Minimal aarch64-w64-mingw32 C implementation to cross-compile
hello-world with libgcc for Windows Arm64 using MinGW.
2. Extension of the aarch64-w64-mingw32 C implementation to
cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All
packages successfully pass tests.
3. Addition of call stack support for debugging, resolution of
optimization issues in the C compiler, and DLL export/import for the
aarch64-w64-mingw32 target.
4. Unit testing integration for aarch64-w64-mingw32 target

The goal is to prepare the first patch series for upstreaming as
soon as possible. This will enable iterative development and
introduce a new target that can potentially be tested and
improved by the community.

If debugging information is a strong blocker for the first patch
series, its priority can be changed. However, it would be
preferable to include it in the second and third patch series,
as originally planned.

Regards,
Evgeny

> On Feb 29, 2024, at 21:59, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> 
> On 29/02/2024 17:55, Andrew Pinski (QUIC) wrote:
>>> -----Original Message-----
>>> From: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
>>> Sent: Thursday, February 29, 2024 9:46 AM
>>> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
>>> Cc: Evgeny Karpov <Evgeny.Karpov@microsoft.com>; Andrew Pinski
>>> <pinskia@gmail.com>; Richard Sandiford <richard.sandiford@arm.com>; gcc-
>>> patches@gcc.gnu.org; 10walls@gmail.com; mark@harmstone.com; Zac
>>> Walker <zacwalker@microsoft.com>; Ron Riddle
>>> <Ron.Riddle@microsoft.com>; Radek Barton <radek.barton@microsoft.com>
>>> Subject: Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW
>>> environments for AArch64
>>> 
>>> WARNING: This email originated from outside of Qualcomm. Please be wary
>>> of any links or attachments, and do not enable macros.
>>> 
>>>> On Feb 29, 2024, at 21:35, Andrew Pinski (QUIC)
>>> <quic_apinski@quicinc.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Evgeny Karpov <Evgeny.Karpov@microsoft.com>
>>>>> Sent: Thursday, February 29, 2024 8:46 AM
>>>>> To: Andrew Pinski <pinskia@gmail.com>
>>>>> Cc: Richard Sandiford <richard.sandiford@arm.com>; gcc-
>>>>> patches@gcc.gnu.org; 10walls@gmail.com; Maxim Kuvyrkov
>>>>> <maxim.kuvyrkov@linaro.org>; mark@harmstone.com; Zac Walker
>>>>> <zacwalker@microsoft.com>; Ron Riddle <Ron.Riddle@microsoft.com>;
>>>>> Radek Barton <radek.barton@microsoft.com>; Andrew Pinski (QUIC)
>>>>> <quic_apinski@quicinc.com>
>>>>> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments
>>>>> for AArch64
>>>>> 
>>>>> Wednesday, February 28, 2024 2:00 AM
>>>>> Andrew Pinski wrote:
>>>>> 
>>>>>> What does this mean with respect to C++ exceptions? Or you using
>>>>>> SJLJ exceptions support or the dwarf unwinding ones without SEH
>>> support?
>>>>>> I am not sure if SJLJ exceptions is well tested any more in GCC either.
>>>>>> 
>>>>>> Also I have a question if you ran the full GCC/G++ testsuites and
>>>>>> what were the results?
>>>>>> If you did run it, did you use a cross compiler or the native
>>>>>> compiler? Did you do a bootstrap (GCC uses C++ but no exceptions
>>> though)?
>>>>> 
>>>>> As mentioned in the cover letter and the thread, the current
>>>>> contribution covers only the C scope.
>>>>> Exception handling is fully disabled for now.
>>>>> There is an experimental build with C++ and SEH, however, it is not
>>>>> included in the plan for the current contribution.
>>>>> 
>>>>> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-
>>> build
>>>>> 
>>>>>> If you run using a cross compiler, did you use ssh or some other
>>>>>> route to run the applications?
>>>>>> 
>>>>>> Thanks,
>>>>>> Andrew Pinski
>>>>> 
>>>>> GitHub Actions are used to cross-compile toolchains, packages and
>>>>> tests, and execute tests on Windows Arm64.
>>>> 
>>>> This does not answer my question because what you are running is just
>>> simple testcases and not the FULL GCC testsuite.
>>>> So again have you ran the GCC testsuite and do you have a dejagnu board to
>>> be able to execute the binaries?
>>>> I think without the GCC testsuite ran to find all of the known failures, you are
>>> going to be running into many issues.
>>>> The GCC testsuite includes many tests for ABI corner cases and many
>>> features that you will most likely not think about testing using your simple
>>> testcases.
>>>> In fact I suspect there will be some of the aarch64 testcases which will need
>>> to be modified for the windows ABI which you have not done yet.
>>> 
>>> Hi Andrew,
>>> 
>>> We (Linaro) have a prototype CI loop setup for testing aarch64-w64-
>>> mingw32, and we have results for gcc-c and libatomic -- see [1].
>>> 
>>> The results are far from clean, but that's expected.  This patch series aims at
>>> enabling C hello-world only, and subsequent patch series will improve the
>>> state of the port.
>>> 
>>> [1] https://ci.linaro.org/job/tcwg_gnu_mingw_check_gcc--master-woa64-
>>> build/6/artifact/artifacts/sumfiles/
>> 
>> Looking at these results, this port is not in any shape or form to be upstreamed right now. Even simple -g will cause failures.
>> Note we don't need a clean testsuite run but the patch series is not even allowing enabling hello world due to the -g not being able to used.
>> 
> 
> It seemed to me as though the patch was posted for comments, not for immediate inclusion.  I agree this isn't ready for committing yet, but neither should the submitters wait until it's perfect before posting it.
> 
> I think it's gcc-15 material, so now is about the right time to be thinking about it.

Hi Andrew,

I agree with Richard.  This patch series is large as is, and it has clear goals:
1. Enable aarch64-w64-mingw32 to compile C-language hello-world.
2. Not regress any other targets.

As far as I know, it achieves both, but both Microsoft and Linaro will do additional testing on x86_64-w64-mingw32 to confirm.

There are more features and fixes for aarch64-w64-mingw32 waiting in the development repos on github, but I don't see any point in cleaning them up and preparing for submission before this already-quiet-large patchset if reviewed.

Thank you,

--
Maxim Kuvyrkov
https://www.linaro.org