diff mbox series

[v1,02/13] aarch64: The aarch64-w64-mingw32 target implements

Message ID VI1PR83MB04312A9E764DE743D605811BF8572@VI1PR83MB0431.EURPRD83.prod.outlook.com
State New
Headers show
Series Add aarch64-w64-mingw32 target | expand

Commit Message

Evgeny Karpov Feb. 21, 2024, 6:26 p.m. UTC
From 5cab07f01f66ba162b7d542e1a61c96f49942331 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 15:32:08 +0100
Subject: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements
 the MS ABI

Two ABIs for aarch64 have been defined for different platforms.

gcc/ChangeLog:

	* config/aarch64/aarch64-opts.h (enum calling_abi): Define
	two ABIs.
---
 gcc/config/aarch64/aarch64-opts.h | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Richard Earnshaw (lists) Feb. 22, 2024, 11:40 a.m. UTC | #1
On 21/02/2024 18:26, Evgeny Karpov wrote:
> 
+/* Available call ABIs.  */
+enum calling_abi
+{
+  AARCH64_EABI = 0,
+  MS_ABI = 1
+};
+

The convention in this file seems to be that all enum types to start with aarch64.  Also, the enumeration values should start with the name of the enumeration type in upper case, so:

enum aarch64_calling_abi
{
  AARCH64_CALLING_ABI_EABI,
  AARCH64_CALLING_ABI_MS
};

or something very much like that.

R.
Evgeny Karpov Feb. 23, 2024, 2:22 p.m. UTC | #2
The calling ABI enum definition has been done following a similar convention in 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-opts.h;h=ef2825803b32001b9632769bdff196d1e43d27ba;hb=refs/heads/master#l41

MS_ABI is used in gcc/config/i386/mingw32.h and gcc/config/i386/winnt-d.cc
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/mingw32.h;h=58304fc55f629648e47490fd3c0f3db3858e4fd8;hb=refs/heads/master#l22

These files are moved to the mingw folder in the patch series.
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240221/5e75c464/attachment.txt

What do you think about this change for v2?

+/* Available call ABIs.  */
+enum aarch64_calling_abi
+{
+  AARCH64_CALLING_ABI_EABI,
+  AARCH64_CALLING_ABI_MS,
+  MS_ABI = AARCH64_CALLING_ABI_MS
+};
+

Regards,
Evgeny


Thursday, February 22, 2024 12:40 PM
Richard Earnshaw (lists) wrote:

>
+/* Available call ABIs.  */
+enum calling_abi
+{
+  AARCH64_EABI = 0,
+  MS_ABI = 1
+};
+

The convention in this file seems to be that all enum types to start with aarch64.  Also, the enumeration values should start with the name of the enumeration type in upper case, so:

enum aarch64_calling_abi
{
  AARCH64_CALLING_ABI_EABI,
  AARCH64_CALLING_ABI_MS
};

or something very much like that.

R.
Richard Sandiford Feb. 23, 2024, 5:49 p.m. UTC | #3
Evgeny Karpov <Evgeny.Karpov@microsoft.com> writes:
> The calling ABI enum definition has been done following a similar convention in 
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-opts.h;h=ef2825803b32001b9632769bdff196d1e43d27ba;hb=refs/heads/master#l41
>
> MS_ABI is used in gcc/config/i386/mingw32.h and gcc/config/i386/winnt-d.cc
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/mingw32.h;h=58304fc55f629648e47490fd3c0f3db3858e4fd8;hb=refs/heads/master#l22
>
> These files are moved to the mingw folder in the patch series.
> https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240221/5e75c464/attachment.txt
>
> What do you think about this change for v2?
>
> +/* Available call ABIs.  */
> +enum aarch64_calling_abi
> +{
> +  AARCH64_CALLING_ABI_EABI,
> +  AARCH64_CALLING_ABI_MS,
> +  MS_ABI = AARCH64_CALLING_ABI_MS
> +};
> +

How is MS_ABI used in practice?  When I apply locally, it looks like
the two non-x86 uses are in:

gcc/config/mingw/mingw32.h:      if (TARGET_64BIT && ix86_abi == MS_ABI)                        \
gcc/config/mingw/winnt-d.cc:  if (TARGET_64BIT && ix86_abi == MS_ABI)

But these should fail to build if used, because AFAICT there's no
definition of ix86_abi on aarch64.

The first match is in EXTRA_OS_CPP_BUILTINS, but I couldn't see any uses
of that in aarch64 code, which would explain why everything builds OK.
The winnt-d.cc occurence looks like it would break the build with the
D frontend enabled though.

Are there two distinct ABIs for aarch64-*-mingw*?  Or are these
distinctions ignored on aarch64 and just retained for compatibility?

If there are two distinct ABIs then we should probably add them to
aarch64_arm_pcs.  But if there is only a single ABI, we should probably
avoid adding calling_abi altogether and instead provide a macro like
TARGET_IS_MS_ABI that aarch64 and x86 can define differently.

(To be clear, I don't think the different handling of x18 matters
for the PCS classification.  That's an orthogonal platform property
that applies to all PCS variants equally.  No-one had suggested
otherwise, just wanted to say in case. :-) )

Thanks,
Richard

>
> Regards,
> Evgeny
>
>
> Thursday, February 22, 2024 12:40 PM
> Richard Earnshaw (lists) wrote:
>
>>
> +/* Available call ABIs.  */
> +enum calling_abi
> +{
> +  AARCH64_EABI = 0,
> +  MS_ABI = 1
> +};
> +
>
> The convention in this file seems to be that all enum types to start with aarch64.  Also, the enumeration values should start with the name of the enumeration type in upper case, so:
>
> enum aarch64_calling_abi
> {
>   AARCH64_CALLING_ABI_EABI,
>   AARCH64_CALLING_ABI_MS
> };
>
> or something very much like that.
>
> R.
Andrew Pinski Feb. 23, 2024, 5:54 p.m. UTC | #4
On Fri, Feb 23, 2024 at 9:51 AM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Evgeny Karpov <Evgeny.Karpov@microsoft.com> writes:
> > The calling ABI enum definition has been done following a similar convention in
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-opts.h;h=ef2825803b32001b9632769bdff196d1e43d27ba;hb=refs/heads/master#l41
> >
> > MS_ABI is used in gcc/config/i386/mingw32.h and gcc/config/i386/winnt-d.cc
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/mingw32.h;h=58304fc55f629648e47490fd3c0f3db3858e4fd8;hb=refs/heads/master#l22
> >
> > These files are moved to the mingw folder in the patch series.
> > https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240221/5e75c464/attachment.txt
> >
> > What do you think about this change for v2?
> >
> > +/* Available call ABIs.  */
> > +enum aarch64_calling_abi
> > +{
> > +  AARCH64_CALLING_ABI_EABI,
> > +  AARCH64_CALLING_ABI_MS,
> > +  MS_ABI = AARCH64_CALLING_ABI_MS
> > +};
> > +
>
> How is MS_ABI used in practice?  When I apply locally, it looks like
> the two non-x86 uses are in:
>
> gcc/config/mingw/mingw32.h:      if (TARGET_64BIT && ix86_abi == MS_ABI)                        \
> gcc/config/mingw/winnt-d.cc:  if (TARGET_64BIT && ix86_abi == MS_ABI)
>
> But these should fail to build if used, because AFAICT there's no
> definition of ix86_abi on aarch64.
>
> The first match is in EXTRA_OS_CPP_BUILTINS, but I couldn't see any uses
> of that in aarch64 code, which would explain why everything builds OK.
> The winnt-d.cc occurence looks like it would break the build with the
> D frontend enabled though.
>
> Are there two distinct ABIs for aarch64-*-mingw*?  Or are these
> distinctions ignored on aarch64 and just retained for compatibility?

There is arm64ec ABI defined for aarch64 windows which is a different
ABI from the standard windows aarch64 ABI, though I am not sure if it
supported with the patches here.
It is documented at
https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-conventions?view=msvc-170
.

Thanks,
Andrew

>
> If there are two distinct ABIs then we should probably add them to
> aarch64_arm_pcs.  But if there is only a single ABI, we should probably
> avoid adding calling_abi altogether and instead provide a macro like
> TARGET_IS_MS_ABI that aarch64 and x86 can define differently.
>
> (To be clear, I don't think the different handling of x18 matters
> for the PCS classification.  That's an orthogonal platform property
> that applies to all PCS variants equally.  No-one had suggested
> otherwise, just wanted to say in case. :-) )
>
> Thanks,
> Richard
>
> >
> > Regards,
> > Evgeny
> >
> >
> > Thursday, February 22, 2024 12:40 PM
> > Richard Earnshaw (lists) wrote:
> >
> >>
> > +/* Available call ABIs.  */
> > +enum calling_abi
> > +{
> > +  AARCH64_EABI = 0,
> > +  MS_ABI = 1
> > +};
> > +
> >
> > The convention in this file seems to be that all enum types to start with aarch64.  Also, the enumeration values should start with the name of the enumeration type in upper case, so:
> >
> > enum aarch64_calling_abi
> > {
> >   AARCH64_CALLING_ABI_EABI,
> >   AARCH64_CALLING_ABI_MS
> > };
> >
> > or something very much like that.
> >
> > R.
Martin Storsjö Feb. 23, 2024, 8:37 p.m. UTC | #5
On Fri, 23 Feb 2024, Richard Sandiford wrote:

> Are there two distinct ABIs for aarch64-*-mingw*?  Or are these 
> distinctions ignored on aarch64 and just retained for compatibility?

On Windows on AArch64, the calling convention normally matches regular 
AAPCS64 - so the ms_abi attribute normally has no effect. However, for 
variadic functions, the calling convention differs, so the ms_abi 
attribute could be used to implement functions with the Windows vararg 
calling convention on Linux.

(As far as I know, the correct Windows vararg calling convention is not 
yet implemented in this patch series, but would be a later addition.)

Clang/LLVM does implement the Windows AArch64 vararg calling convention, 
and it used to be necessary for Wine on AArch64 before, but as Jacek 
mentioned, it's no longer needed by Wine.

ARM64EC is an entirely different thing though, both out of scope for this 
patchset, and also a much bigger thing than an MS_ABI attribute.

// Martin
Evgeny Karpov Feb. 23, 2024, 9:32 p.m. UTC | #6
Hi Richard,

Thank you for your review!

The MS_ABI definition is for the x86/x64 MS ABI, and it's clear that it shouldn't be used on aarch64.

The AARCH64_CALLING_ABI_MS definition resolves the issue.
It just needs to be properly handled in mingw32.h.

The change below is sufficient to resolve the ABI usage in mingw.

Regards,
Evgeny

gcc/config.gcc
-       tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"
+       tm_defines="${tm_defines} TARGET_AARCH64_MS_ABI=1"

config/aarch64/aarch64-opts.h

+/* Available call ABIs.  */
+enum aarch64_calling_abi
+{
+  AARCH64_CALLING_ABI_EABI,
+  AARCH64_CALLING_ABI_MS
+};
+

gcc/config/mingw/mingw32.h
@@ -19,7 +19,11 @@

-#define DEFAULT_ABI MS_ABI
+#if defined (TARGET_AARCH64_MS_ABI)
+# define DEFAULT_ABI AARCH64_CALLING_ABI_MS
+#else
+# define DEFAULT_ABI MS_ABI
+#endif



-----Original Message-----
Friday, February 23, 2024 6:50 PM
Richard Sandiford wrote:

> What do you think about this change for v2?
>
> +/* Available call ABIs.  */
> +enum aarch64_calling_abi
> +{
> +  AARCH64_CALLING_ABI_EABI,
> +  AARCH64_CALLING_ABI_MS,
> +  MS_ABI = AARCH64_CALLING_ABI_MS
> +};
> +

How is MS_ABI used in practice?  When I apply locally, it looks like the two non-x86 uses are in:

gcc/config/mingw/mingw32.h:      if (TARGET_64BIT && ix86_abi == MS_ABI)                        \
gcc/config/mingw/winnt-d.cc:  if (TARGET_64BIT && ix86_abi == MS_ABI)

But these should fail to build if used, because AFAICT there's no definition of ix86_abi on aarch64.

The first match is in EXTRA_OS_CPP_BUILTINS, but I couldn't see any uses of that in aarch64 code, which would explain why everything builds OK.
The winnt-d.cc occurence looks like it would break the build with the D frontend enabled though.

Are there two distinct ABIs for aarch64-*-mingw*?  Or are these distinctions ignored on aarch64 and just retained for compatibility?

If there are two distinct ABIs then we should probably add them to aarch64_arm_pcs.  But if there is only a single ABI, we should probably avoid adding calling_abi altogether and instead provide a macro like TARGET_IS_MS_ABI that aarch64 and x86 can define differently.

(To be clear, I don't think the different handling of x18 matters for the PCS classification.  That's an orthogonal platform property that applies to all PCS variants equally.  No-one had suggested otherwise, just wanted to say in case. :-) )

Thanks,
Richard
Evgeny Karpov Feb. 23, 2024, 9:47 p.m. UTC | #7
Hi Martin,

Thank you for the clarification regarding the vararg implementation.
It is correct. The work is still in progress and will be included in
a later patch series.

ARM64EC is a separate work, which is outside the scope of the current
contribution plan.

Regards,
Evgeny

-----Original Message-----
Friday, February 23, 2024 9:37 PM
Martin Storsjö wrote: 

On Fri, 23 Feb 2024, Richard Sandiford wrote:

> Are there two distinct ABIs for aarch64-*-mingw*?  Or are these 
> distinctions ignored on aarch64 and just retained for compatibility?

(As far as I know, the correct Windows vararg calling convention is not yet implemented in this patch series, but would be a later addition.)

ARM64EC is an entirely different thing though, both out of scope for this patchset, and also a much bigger thing than an MS_ABI attribute.

// Martin
Mark Harmstone Feb. 25, 2024, 9:15 p.m. UTC | #8
On 23/2/24 17:54, Andrew Pinski wrote:
> There is arm64ec ABI defined for aarch64 windows which is a different
> ABI from the standard windows aarch64 ABI, though I am not sure if it
> supported with the patches here.
> It is documented at
> https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-conventions?view=msvc-170
> .

ARM64EC would also need a lot of work in binutils, and AFAIK no-one's been working on that yet.

Mark
diff mbox series

Patch

diff --git a/gcc/config/aarch64/aarch64-opts.h b/gcc/config/aarch64/aarch64-opts.h
index a05c0d3ded1..77e3eae9595 100644
--- a/gcc/config/aarch64/aarch64-opts.h
+++ b/gcc/config/aarch64/aarch64-opts.h
@@ -131,4 +131,11 @@  enum aarch64_early_ra_scope {
   AARCH64_EARLY_RA_NONE
 };
 
+/* Available call ABIs.  */
+enum calling_abi
+{
+  AARCH64_EABI = 0,
+  MS_ABI = 1
+};
+
 #endif