[3/4] gdb: distinguish GNU and MSVC flavors of the Windows OS ABI

  The GNU (MinGW) and MSVC ABIs on Windows are not the same.  They
differ in long double, in the whole C++ ABI, and in other details.
GDB has so far had a single GDB_OSABI_WINDOWS OS ABI covering both.

Unfortunately, it is not possible to reliably distinguish which ABI is
in use from the binary alone -- a PE image doesn't say which
compiler's ABI (or ABIs) it follows.

GDB does have the concept of default OSABI, though, so we can make GDB
pick a different default Windows OSABI depending on which --target GDB
was configured with.  So e.g, a GDB configured with
--target=x86_64-pc-windows-msvc should default to the Windows MSVC
ABI, and GDB configured for MinGW should default to the Windows GNU
ABI.  That's what this patch does.

Introduce two new OS ABIs:

 - GDB_OSABI_WINDOWS_GNU
 - GDB_OSABI_WINDOWS_MSVC

and keep GDB_OSABI_WINDOWS as a generic "Windows, flavor
undetermined".

The osabi sniffers and gdbserver's target description continue
reporting the generic value.  GDB resolves the generic Windows value
to a concrete flavor, after consulting all the OS ABI sources.

In configure.tgt, we now map "mingw" to GDB_OSABI_WINDOWS_GNU and the
"windows-msvc" to GDB_OSABI_WINDOWS_MSVC.  A bare "windows" OS in the
triplet, with no environment, maps to MSVC ABI, same as what LLVM
does.

An explicit GNU environment in the triplet (like e.g.,
x86_64-pc-windows-gnu) maps to GDB_OSABI_WINDOWS_GNU.  Note that
config.sub does not accept a "windows-gnu" triplet today.  This
triplet is used by MinGW ABI clang and Rust, though, so I still think
we should add it now so that the osabi mapping stays correct if
windows-gnu is ever wired up throughout the tree.

"set osabi" gains the two new "Windows-GNU" and "Windows-MSVC" values.
The generic "Windows" value remains selectable too -- it is registered
as a name without a handler via the new gdbarch_add_osabi_name
function, since it is never the final ABI of a gdbarch, only a request
to let GDB pick the flavor.  Selecting it goes through the same
resolution as auto-detection.

Because selecting the generic "Windows" resolves to a different OS ABI
than the one named, "show osabi" reports both the selected value and
the one it resolved to, e.g.:

 (gdb) set osabi Windows
 (gdb) show osabi
 The current OS ABI is "Windows" (resolved to "Windows-GNU").
 The default OS ABI is "GNU/Linux".

This is similar to "set osabi auto", but uses "resolved to" rather
than "currently" as the latter would read a bit awkward and unclear with the repeated "current", as in:

 (current OS ABI is "foo" (currently "bar").
  ^^^^^^^                  ^^^^^^^^^

Change-Id: Ic20ce4085052bdb9b78d28d399d6907f6fced0c6
---
 gdb/NEWS                   | 16 ++++++++++++++++
 gdb/aarch64-windows-tdep.c |  5 ++++-
 gdb/amd64-windows-tdep.c   |  6 +++++-
 gdb/arch-utils.c           | 18 ++++++++++++++++++
 gdb/configure.tgt          |  8 ++++++--
 gdb/doc/gdb.texinfo        | 15 +++++++++++++++
 gdb/i386-windows-tdep.c    |  6 +++++-
 gdb/osabi.c                | 32 +++++++++++++++++++++++++++-----
 gdb/osabi.h                |  8 ++++++++
 gdb/windows-tdep.h         |  5 +++--
 gdbsupport/osabi.def       |  2 ++
 11 files changed, 109 insertions(+), 12 deletions(-)
  

> From: Pedro Alves <pedro@palves.net>
> Date: Tue, 14 Jul 2026 01:45:06 +0100
> 
>  gdb/NEWS                   | 16 ++++++++++++++++
>  gdb/aarch64-windows-tdep.c |  5 ++++-
>  gdb/amd64-windows-tdep.c   |  6 +++++-
>  gdb/arch-utils.c           | 18 ++++++++++++++++++
>  gdb/configure.tgt          |  8 ++++++--
>  gdb/doc/gdb.texinfo        | 15 +++++++++++++++
>  gdb/i386-windows-tdep.c    |  6 +++++-
>  gdb/osabi.c                | 32 +++++++++++++++++++++++++++-----
>  gdb/osabi.h                |  8 ++++++++
>  gdb/windows-tdep.h         |  5 +++--
>  gdbsupport/osabi.def       |  2 ++
>  11 files changed, 109 insertions(+), 12 deletions(-)

Thanks.

> diff --git a/gdb/NEWS b/gdb/NEWS
> index ec9b5a33787..cf3948f87e4 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -103,6 +103,16 @@
>    everywhere GDB shows a filename/dirname: source filenames,
>    executable filename, shared libraries, the cd/pwd commands, etc.
>  
> +* GDB now distinguishes between the GNU (MinGW) and MSVC Windows ABIs.
> +
> +  The "set osabi" command accepts two new values, "Windows-GNU" and
> +  "Windows-MSVC".  The existing "Windows" value continues to work and
> +  now means "let GDB pick the flavor": GDB uses the configured default
> +  OS ABI (from --target) when that is a Windows flavor, and otherwise
> +  assumes the GNU flavor.  E.g., --target=x86_64-pc-windows-msvc
> +  defaults to the MSVC ABI, and --target=x86_64-w64-mingw32 defaults
> +  to GNU ABI.  See "New targets" entry below.

This part is okay, but I think it would make sense to tell which
compilers produce binaries of Windows-MSVC ABI.  E.g., does the above
mean that GDB will now be able to debug programs produces by MSVC,
including use of the PDB debug data files?

Also, you only mention the 64-bit host and target triplets, but does
that mean this is limited to 64-bit Windows programs?

> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -28680,6 +28680,15 @@ When @value{GDBN} is debugging the AArch64 architecture, it provides a
>  @code{longjmp} when debugging binaries that use the @sc{newlib} C library.
>  The ``Newlib'' OS ABI can be selected by @code{set osabi Newlib}.
>  
> +On Windows, the GNU (MinGW) and MSVC toolchains use different ABIs.
> +For example, they disagree on the size of @code{long double}.
> +@value{GDBN} provides a separate OS ABI for each: ``Windows-GNU'' and
> +``Windows-MSVC''.  A generic ``Windows'' OS ABI is also available.  It
> +does not select a flavor directly, but asks @value{GDBN} to pick one:
> +@value{GDBN} uses the OS ABI it was configured with by default (from
> +the @code{--target} configure option) when that is a Windows flavor,
> +and otherwise assumes the GNU flavor.

Should we have a cross-reference here to the "Configure Options" node?

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
  

On 2026-07-14 12:57, Eli Zaretskii wrote:

>> diff --git a/gdb/NEWS b/gdb/NEWS
>> index ec9b5a33787..cf3948f87e4 100644
>> --- a/gdb/NEWS
>> +++ b/gdb/NEWS
>> @@ -103,6 +103,16 @@
>>    everywhere GDB shows a filename/dirname: source filenames,
>>    executable filename, shared libraries, the cd/pwd commands, etc.
>>  
>> +* GDB now distinguishes between the GNU (MinGW) and MSVC Windows ABIs.
>> +
>> +  The "set osabi" command accepts two new values, "Windows-GNU" and
>> +  "Windows-MSVC".  The existing "Windows" value continues to work and
>> +  now means "let GDB pick the flavor": GDB uses the configured default
>> +  OS ABI (from --target) when that is a Windows flavor, and otherwise
>> +  assumes the GNU flavor.  E.g., --target=x86_64-pc-windows-msvc
>> +  defaults to the MSVC ABI, and --target=x86_64-w64-mingw32 defaults
>> +  to GNU ABI.  See "New targets" entry below.
> 
> This part is okay, but I think it would make sense to tell which
> compilers produce binaries of Windows-MSVC ABI.  E.g., does the above
> mean that GDB will now be able to debug programs produces by MSVC,
> including use of the PDB debug data files?
> 
> Also, you only mention the 64-bit host and target triplets, but does
> that mean this is limited to 64-bit Windows programs?

That was an example, and the "New targets" section being pointed at has the
32-bit x86 and AArch64 triplets.  But I can try to make it clearer, along with
addressing your other points.

How about this?

* GDB now distinguishes between the GNU (MinGW) and MSVC Windows ABIs.

  The "set osabi" command accepts two new values, "Windows-GNU" and
  "Windows-MSVC".  The GNU ABI is for code produced by MinGW
  toolchains, while the MSVC ABI is for code produced by Microsoft's
  MSVC compiler (though see the PDB note below), or Clang targeting
  one of {i686,aarch64,x86_64}-pc-windows-msvc.  The existing
  "Windows" value continues to work and now means "let GDB pick the
  flavor": GDB uses the configured default OS ABI (from --target) when
  that is a Windows flavor, and otherwise assumes the GNU flavor.  For
  example, --target=x86_64-pc-windows-msvc defaults to the MSVC ABI,
  and --target=x86_64-w64-mingw32 defaults to GNU ABI.  Similarly for
  the i686 and AArch64 variants.  See "New targets" entry below.

  Currently, GDB is aware that "long double" differs between the two
  ABIs.  GDB does not yet support the MSVC C++ ABI (demangling scheme,
  C++ object layout, etc.) or PDB debug information.


Both MSFT C++ ABI and PDB support are in the works, but of course I
cannot guarantee when they'll be ready.


> 
>> --- a/gdb/doc/gdb.texinfo
>> +++ b/gdb/doc/gdb.texinfo
>> @@ -28680,6 +28680,15 @@ When @value{GDBN} is debugging the AArch64 architecture, it provides a
>>  @code{longjmp} when debugging binaries that use the @sc{newlib} C library.
>>  The ``Newlib'' OS ABI can be selected by @code{set osabi Newlib}.
>>  
>> +On Windows, the GNU (MinGW) and MSVC toolchains use different ABIs.
>> +For example, they disagree on the size of @code{long double}.
>> +@value{GDBN} provides a separate OS ABI for each: ``Windows-GNU'' and
>> +``Windows-MSVC''.  A generic ``Windows'' OS ABI is also available.  It
>> +does not select a flavor directly, but asks @value{GDBN} to pick one:
>> +@value{GDBN} uses the OS ABI it was configured with by default (from
>> +the @code{--target} configure option) when that is a Windows flavor,
>> +and otherwise assumes the GNU flavor.
> 
> Should we have a cross-reference here to the "Configure Options" node?

Sounds good.  Added it at the end, like:

 +the @code{--target} configure option) when that is a Windows flavor,
 +and otherwise assumes the GNU flavor.  @xref{Configure Options}.

Below's the full updated patch.

From 65b5e4cc18c73b4cfcad11e93f67939216b994f9 Mon Sep 17 00:00:00 2001
From: Pedro Alves <pedro@palves.net>
Date: Mon, 13 Jul 2026 14:27:44 +0100
Subject: [PATCH] gdb: distinguish GNU and MSVC flavors of the Windows OS ABI

The GNU (MinGW) and MSVC ABIs on Windows are not the same.  They
differ in long double, in the whole C++ ABI, and in other details.
GDB has so far had a single GDB_OSABI_WINDOWS OS ABI covering both.

Unfortunately, it is not possible to reliably distinguish which ABI is
in use from the binary alone -- a PE image doesn't say which
compiler's ABI (or ABIs) it follows.

GDB does have the concept of default OSABI, though, so we can make GDB
pick a different default Windows OSABI depending on which --target GDB
was configured with.  So e.g, a GDB configured with
--target=x86_64-pc-windows-msvc should default to the Windows MSVC
ABI, and GDB configured for MinGW should default to the Windows GNU
ABI.  That's what this patch does.

Introduce two new OS ABIs:

 - GDB_OSABI_WINDOWS_GNU
 - GDB_OSABI_WINDOWS_MSVC

and keep GDB_OSABI_WINDOWS as a generic "Windows, flavor
undetermined".

The osabi sniffers and gdbserver's target description continue
reporting the generic value.  GDB resolves the generic Windows value
to a concrete flavor, after consulting all the OS ABI sources.

In configure.tgt, we now map "mingw" to GDB_OSABI_WINDOWS_GNU and the
"windows-msvc" to GDB_OSABI_WINDOWS_MSVC.  A bare "windows" OS in the
triplet, with no environment, maps to MSVC ABI, same as what LLVM
does.

An explicit GNU environment in the triplet (like e.g.,
x86_64-pc-windows-gnu) maps to GDB_OSABI_WINDOWS_GNU.  Note that
config.sub does not accept a "windows-gnu" triplet today.  This
triplet is used by MinGW ABI clang and Rust, though, so I still think
we should add it now so that the osabi mapping stays correct if
windows-gnu is ever wired up throughout the tree.

"set osabi" gains the two new "Windows-GNU" and "Windows-MSVC" values.
The generic "Windows" value remains selectable too -- it is registered
as a name without a handler via the new gdbarch_add_osabi_name
function, since it is never the final ABI of a gdbarch, only a request
to let GDB pick the flavor.  Selecting it goes through the same
resolution as auto-detection.

Because selecting the generic "Windows" resolves to a different OS ABI
than the one named, "show osabi" reports both the selected value and
the one it resolved to, e.g.:

 (gdb) set osabi Windows
 (gdb) show osabi
 The current OS ABI is "Windows" (resolved to "Windows-GNU").
 The default OS ABI is "GNU/Linux".

This is similar to "set osabi auto", but uses "resolved to" rather
than "currently" as the latter would read a bit awkward and unclear with the repeated "current", as in:

 (current OS ABI is "foo" (currently "bar").
  ^^^^^^^                  ^^^^^^^^^

Change-Id: Ic20ce4085052bdb9b78d28d399d6907f6fced0c6
---
 gdb/NEWS                   | 24 ++++++++++++++++++++++++
 gdb/aarch64-windows-tdep.c |  5 ++++-
 gdb/amd64-windows-tdep.c   |  6 +++++-
 gdb/arch-utils.c           | 18 ++++++++++++++++++
 gdb/configure.tgt          |  8 ++++++--
 gdb/doc/gdb.texinfo        | 15 +++++++++++++++
 gdb/i386-windows-tdep.c    |  6 +++++-
 gdb/osabi.c                | 32 +++++++++++++++++++++++++++-----
 gdb/osabi.h                |  8 ++++++++
 gdb/windows-tdep.h         |  5 +++--
 gdbsupport/osabi.def       |  2 ++
 11 files changed, 117 insertions(+), 12 deletions(-)

diff --git a/gdb/NEWS b/gdb/NEWS
index ec9b5a33787..5eb927011c0 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -103,6 +103,24 @@
   everywhere GDB shows a filename/dirname: source filenames,
   executable filename, shared libraries, the cd/pwd commands, etc.
 
+* GDB now distinguishes between the GNU (MinGW) and MSVC Windows ABIs.
+
+  The "set osabi" command accepts two new values, "Windows-GNU" and
+  "Windows-MSVC".  The GNU ABI is for code produced by MinGW
+  toolchains, while the MSVC ABI is for code produced by Microsoft's
+  MSVC compiler (though see the PDB note below), or Clang targeting
+  one of {i686,aarch64,x86_64}-pc-windows-msvc.  The existing
+  "Windows" value continues to work and now means "let GDB pick the
+  flavor": GDB uses the configured default OS ABI (from --target) when
+  that is a Windows flavor, and otherwise assumes the GNU flavor.  For
+  example, --target=x86_64-pc-windows-msvc defaults to the MSVC ABI,
+  and --target=x86_64-w64-mingw32 defaults to GNU ABI.  Similarly for
+  the i686 and AArch64 variants.  See "New targets" entry below.
+
+  Currently, GDB is aware that "long double" differs between the two
+  ABIs.  GDB does not yet support the MSVC C++ ABI (demangling scheme,
+  C++ object layout, etc.) or PDB debug information.
+
 * GDB now supports libipt v2.2 events originating from Event Tracing (set
   record btrace pt event-tracing on) on a FRED-enabled system and from
   Trigger Tracing.
@@ -128,6 +146,12 @@ GNU/Linux/MicroBlaze (gdbserver) microblazeel-*linux*
 
 AArch64 MinGW                   aarch64-*-mingw*
 
+i386 Windows/MSVC               i[34567]86-*-windows-msvc
+
+amd64 Windows/MSVC              x86_64-*-windows-msvc
+
+AArch64 Windows/MSVC            aarch64-*-windows-msvc
+
 * Deprecated targets
 
 GNU/Linux/S390 32-bit		s390-*-*
diff --git a/gdb/aarch64-windows-tdep.c b/gdb/aarch64-windows-tdep.c
index 7932f27b83b..647ee500dd0 100644
--- a/gdb/aarch64-windows-tdep.c
+++ b/gdb/aarch64-windows-tdep.c
@@ -62,8 +62,11 @@ aarch64_windows_osabi_sniffer (bfd *abfd)
 
 INIT_GDB_FILE (aarch64_windows_tdep)
 {
-  gdbarch_register_osabi (bfd_arch_aarch64, 0, GDB_OSABI_WINDOWS,
+  gdbarch_register_osabi (bfd_arch_aarch64, 0, GDB_OSABI_WINDOWS_GNU,
 			  aarch64_windows_init_abi);
+  gdbarch_register_osabi (bfd_arch_aarch64, 0, GDB_OSABI_WINDOWS_MSVC,
+			  aarch64_windows_init_abi);
+  gdbarch_add_osabi_name (GDB_OSABI_WINDOWS);
 
   gdbarch_register_osabi_sniffer (bfd_arch_aarch64, bfd_target_coff_flavour,
 				  aarch64_windows_osabi_sniffer);
diff --git a/gdb/amd64-windows-tdep.c b/gdb/amd64-windows-tdep.c
index 85f7ac51a4f..68dd2f354fe 100644
--- a/gdb/amd64-windows-tdep.c
+++ b/gdb/amd64-windows-tdep.c
@@ -1392,8 +1392,12 @@ amd64_cygwin_core_osabi_sniffer (bfd *abfd)
 
 INIT_GDB_FILE (amd64_windows_tdep)
 {
-  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64, GDB_OSABI_WINDOWS,
+  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64, GDB_OSABI_WINDOWS_GNU,
 			  amd64_windows_init_abi);
+  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64, GDB_OSABI_WINDOWS_MSVC,
+			  amd64_windows_init_abi);
+  gdbarch_add_osabi_name (GDB_OSABI_WINDOWS);
+
   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64, GDB_OSABI_CYGWIN,
 			  amd64_cygwin_init_abi);
 
diff --git a/gdb/arch-utils.c b/gdb/arch-utils.c
index e959788bd3b..473a352e781 100644
--- a/gdb/arch-utils.c
+++ b/gdb/arch-utils.c
@@ -825,6 +825,24 @@ gdbarch_info_fill (struct gdbarch_info *info)
   if (info->osabi == GDB_OSABI_UNKNOWN)
     info->osabi = GDB_OSABI_DEFAULT;
 #endif
+
+  /* A generic "Windows" OS ABI means a PE binary whose flavor --
+     GNU (MinGW) or MSVC -- could not be determined.  The osabi
+     sniffers and gdbserver's target description both report the
+     generic "Windows" OS ABI, because neither can tell the two
+     flavors apart from the binary alone.  Resolve it here to a
+     concrete flavor: use the configured default if that is itself a
+     Windows flavor, otherwise assume GNU.  */
+  if (info->osabi == GDB_OSABI_WINDOWS)
+    {
+      info->osabi = GDB_OSABI_WINDOWS_GNU;
+#ifdef GDB_OSABI_DEFAULT
+      if (GDB_OSABI_DEFAULT == GDB_OSABI_WINDOWS_GNU
+	  || GDB_OSABI_DEFAULT == GDB_OSABI_WINDOWS_MSVC)
+	info->osabi = GDB_OSABI_DEFAULT;
+#endif
+    }
+
   /* If we still don't know which osabi to pick, pick none.  */
   if (info->osabi == GDB_OSABI_UNKNOWN)
     info->osabi = GDB_OSABI_NONE;
diff --git a/gdb/configure.tgt b/gdb/configure.tgt
index f473f67d8bd..2f164405c16 100644
--- a/gdb/configure.tgt
+++ b/gdb/configure.tgt
@@ -819,10 +819,14 @@ case "${targ}" in
 m68*-*-openbsd* | m88*-*-openbsd* | vax-*-openbsd*) ;;
 *-*-openbsd*)	gdb_osabi=GDB_OSABI_OPENBSD ;;
 *-*-solaris*)	gdb_osabi=GDB_OSABI_SOLARIS ;;
+# Match the Windows OS ABIs before the non-GNU-kernel guard below,
+# which would otherwise swallow the "-gnu" of a windows-gnu (MinGW)
+# triplet and leave gdb_osabi unset.
+*-*-mingw32ce*)	gdb_osabi=GDB_OSABI_WINCE ;;
+*-*-mingw* | *-*-windows*gnu*)	gdb_osabi=GDB_OSABI_WINDOWS_GNU ;;
+*-*-windows*)	gdb_osabi=GDB_OSABI_WINDOWS_MSVC ;;
 *-*-*-gnu*)	;; # prevent non-GNU kernels to match the Hurd rule below
 *-*-gnu*)	gdb_osabi=GDB_OSABI_HURD ;;
-*-*-mingw32ce*)	gdb_osabi=GDB_OSABI_WINCE ;;
-*-*-mingw* | *-*-windows*)	gdb_osabi=GDB_OSABI_WINDOWS ;;
 *-*-cygwin*)	gdb_osabi=GDB_OSABI_CYGWIN ;;
 *-*-dicos*)	gdb_osabi=GDB_OSABI_DICOS ;;
 powerpc-*-aix* | rs6000-*-* | powerpc64-*-aix*)
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index a698b2b8451..9afc22cbdc2 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -28680,6 +28680,15 @@ When @value{GDBN} is debugging the AArch64 architecture, it provides a
 @code{longjmp} when debugging binaries that use the @sc{newlib} C library.
 The ``Newlib'' OS ABI can be selected by @code{set osabi Newlib}.
 
+On Windows, the GNU (MinGW) and MSVC toolchains use different ABIs.
+For example, they disagree on the size of @code{long double}.
+@value{GDBN} provides a separate OS ABI for each: ``Windows-GNU'' and
+``Windows-MSVC''.  A generic ``Windows'' OS ABI is also available.  It
+does not select a flavor directly, but asks @value{GDBN} to pick one:
+@value{GDBN} uses the OS ABI it was configured with by default (from
+the @code{--target} configure option) when that is a Windows flavor,
+and otherwise assumes the GNU flavor.  @xref{Configure Options}.
+
 @table @code
 @item show osabi
 Show the OS ABI currently in use.
@@ -49441,6 +49450,12 @@ An @samp{<osabi>} element has this form:
 @var{abi-name} is an OS ABI name from the same selection accepted by
 @w{@code{set osabi}} (@pxref{ABI, ,Configuring the Current ABI}).
 
+For Windows targets, a stub should report the generic ``Windows'' OS
+ABI rather than ``Windows-GNU'' or ``Windows-MSVC'', as the running
+program does not record which toolchain's ABI it follows.
+@value{GDBN} resolves the generic name to a flavor itself (@pxref{ABI,
+,Configuring the Current ABI}).
+
 @subsection Compatible Architecture
 @cindex @code{<compatible>}
 
diff --git a/gdb/i386-windows-tdep.c b/gdb/i386-windows-tdep.c
index b66483c4b96..b8db0b9d5fb 100644
--- a/gdb/i386-windows-tdep.c
+++ b/gdb/i386-windows-tdep.c
@@ -230,8 +230,12 @@ INIT_GDB_FILE (i386_windows_tdep)
   gdbarch_register_osabi_sniffer (bfd_arch_i386, bfd_target_elf_flavour,
 				  i386_cygwin_core_osabi_sniffer);
 
-  gdbarch_register_osabi (bfd_arch_i386, 0, GDB_OSABI_WINDOWS,
+  gdbarch_register_osabi (bfd_arch_i386, 0, GDB_OSABI_WINDOWS_GNU,
 			  i386_windows_init_abi);
+  gdbarch_register_osabi (bfd_arch_i386, 0, GDB_OSABI_WINDOWS_MSVC,
+			  i386_windows_init_abi);
+  gdbarch_add_osabi_name (GDB_OSABI_WINDOWS);
+
   gdbarch_register_osabi (bfd_arch_i386, 0, GDB_OSABI_CYGWIN,
 			  i386_cygwin_init_abi);
 }
diff --git a/gdb/osabi.c b/gdb/osabi.c
index 49f618610b0..0ebfe07951e 100644
--- a/gdb/osabi.c
+++ b/gdb/osabi.c
@@ -62,7 +62,6 @@ gdbarch_register_osabi (enum bfd_architecture arch, unsigned long machine,
 {
   struct gdb_osabi_handler **handler_p;
   const struct bfd_arch_info *arch_info = bfd_lookup_arch (arch, machine);
-  const char **name_ptr;
 
   /* Registering an OS ABI handler for "unknown" is not allowed.  */
   if (osabi == GDB_OSABI_UNKNOWN)
@@ -101,8 +100,17 @@ gdbarch_register_osabi (enum bfd_architecture arch, unsigned long machine,
   (*handler_p)->osabi = osabi;
   (*handler_p)->init_osabi = init_osabi;
 
-  /* Add this OS ABI to the list of enum values for "set osabi", if it isn't
-     already there.  */
+  /* Add this OS ABI to the list of enum values for "set osabi".  */
+  gdbarch_add_osabi_name (osabi);
+}
+
+/* See osabi.h.  */
+
+void
+gdbarch_add_osabi_name (enum gdb_osabi osabi)
+{
+  const char **name_ptr;
+
   for (name_ptr = gdb_osabi_available_names; *name_ptr; name_ptr ++)
     {
       if (*name_ptr == gdbarch_osabi_name (osabi))
@@ -601,8 +609,22 @@ show_osabi (struct ui_file *file, int from_tty, struct cmd_list_element *c,
 		  "(currently \"%s\").\n"),
 		gdbarch_osabi_name (gdbarch_osabi (get_current_arch ())));
   else
-    gdb_printf (file, _("The current OS ABI is \"%s\".\n"),
-		gdbarch_osabi_name (user_selected_osabi));
+    {
+      /* The OS ABI in effect may differ from the one the user
+	 selected: a generic OS ABI such as "Windows" is resolved to a
+	 concrete one (a Windows flavor) when the gdbarch is
+	 built.  */
+      enum gdb_osabi effective = gdbarch_osabi (get_current_arch ());
+
+      if (effective != user_selected_osabi)
+	gdb_printf (file,
+		    _("The current OS ABI is \"%s\" (resolved to \"%s\").\n"),
+		    gdbarch_osabi_name (user_selected_osabi),
+		    gdbarch_osabi_name (effective));
+      else
+	gdb_printf (file, _("The current OS ABI is \"%s\".\n"),
+		    gdbarch_osabi_name (user_selected_osabi));
+    }
 
   if (GDB_OSABI_DEFAULT != GDB_OSABI_UNKNOWN)
     gdb_printf (file, _("The default OS ABI is \"%s\".\n"),
diff --git a/gdb/osabi.h b/gdb/osabi.h
index 9c9886aba7a..a96dbd96531 100644
--- a/gdb/osabi.h
+++ b/gdb/osabi.h
@@ -38,6 +38,14 @@ void gdbarch_register_osabi (enum bfd_architecture, unsigned long,
 			     void (*)(struct gdbarch_info,
 				      struct gdbarch *));
 
+/* Make OSABI selectable via the "set osabi" command without
+   registering a handler for it.  This is for an OS ABI that is never
+   the final ABI of a gdbarch, but that a user may still want to
+   select -- it is resolved to a concrete ABI elsewhere.  The generic
+   "Windows" OS ABI is one example: it stands for "let GDB pick the
+   GNU or MSVC flavor".  */
+void gdbarch_add_osabi_name (enum gdb_osabi osabi);
+
 /* Lookup the OS ABI corresponding to the specified BFD.  */
 enum gdb_osabi gdbarch_lookup_osabi (bfd *);
 
diff --git a/gdb/windows-tdep.h b/gdb/windows-tdep.h
index 235528ee30b..7cbc6ea9334 100644
--- a/gdb/windows-tdep.h
+++ b/gdb/windows-tdep.h
@@ -41,8 +41,9 @@ extern ULONGEST windows_core_xfer_shared_libraries (struct gdbarch *gdbarch,
 extern std::string windows_core_pid_to_str (struct gdbarch *gdbarch,
 					    ptid_t ptid);
 
-/* To be called from the various GDB_OSABI_WINDOWS handlers for the
-   various Windows architectures and machine types.  */
+/* To be called from the various GDB_OSABI_WINDOWS_GNU and
+   GDB_OSABI_WINDOWS_MSVC handlers for the various Windows
+   architectures and machine types.  */
 
 extern void windows_init_abi (struct gdbarch_info info,
 			      struct gdbarch *gdbarch);
diff --git a/gdbsupport/osabi.def b/gdbsupport/osabi.def
index 230c21f0236..69732b90f43 100644
--- a/gdbsupport/osabi.def
+++ b/gdbsupport/osabi.def
@@ -45,6 +45,8 @@ GDB_OSABI_DEF (WINCE, "WindowsCE", nullptr)
 GDB_OSABI_DEF (GO32, "DJGPP", nullptr)
 GDB_OSABI_DEF (CYGWIN, "Cygwin", nullptr)
 GDB_OSABI_DEF (WINDOWS, "Windows", nullptr)
+GDB_OSABI_DEF (WINDOWS_GNU, "Windows-GNU", nullptr)
+GDB_OSABI_DEF (WINDOWS_MSVC, "Windows-MSVC", nullptr)
 GDB_OSABI_DEF (AIX, "AIX", nullptr)
 GDB_OSABI_DEF (DICOS, "DICOS", nullptr)
 GDB_OSABI_DEF (DARWIN, "Darwin", nullptr)

base-commit: 490469846dcef89fe53668bdbba73591c64bed61
prerequisite-patch-id: ed1cdd12fb2e8aff39333606bd7e09be908d38b2
prerequisite-patch-id: 2573abf27e64de02c68de290f396c180aab7f07c
prerequisite-patch-id: 4ad37c9dcc630915da81f129125a9db1ad21812d
  

On 2026-07-14 18:15, Pedro Alves wrote:
> On 2026-07-14 12:57, Eli Zaretskii wrote:
> 
>>> diff --git a/gdb/NEWS b/gdb/NEWS
>>> index ec9b5a33787..cf3948f87e4 100644
>>> --- a/gdb/NEWS
>>> +++ b/gdb/NEWS
>>> @@ -103,6 +103,16 @@
>>>    everywhere GDB shows a filename/dirname: source filenames,
>>>    executable filename, shared libraries, the cd/pwd commands, etc.
>>>  
>>> +* GDB now distinguishes between the GNU (MinGW) and MSVC Windows ABIs.
>>> +
>>> +  The "set osabi" command accepts two new values, "Windows-GNU" and
>>> +  "Windows-MSVC".  The existing "Windows" value continues to work and
>>> +  now means "let GDB pick the flavor": GDB uses the configured default
>>> +  OS ABI (from --target) when that is a Windows flavor, and otherwise
>>> +  assumes the GNU flavor.  E.g., --target=x86_64-pc-windows-msvc
>>> +  defaults to the MSVC ABI, and --target=x86_64-w64-mingw32 defaults
>>> +  to GNU ABI.  See "New targets" entry below.
>>
>> This part is okay, but I think it would make sense to tell which
>> compilers produce binaries of Windows-MSVC ABI.  E.g., does the above
>> mean that GDB will now be able to debug programs produces by MSVC,
>> including use of the PDB debug data files?
>>
>> Also, you only mention the 64-bit host and target triplets, but does
>> that mean this is limited to 64-bit Windows programs?
> 
> That was an example, and the "New targets" section being pointed at has the
> 32-bit x86 and AArch64 triplets.  But I can try to make it clearer, along with
> addressing your other points.
> 
> How about this?
> 
> * GDB now distinguishes between the GNU (MinGW) and MSVC Windows ABIs.
> 
>   The "set osabi" command accepts two new values, "Windows-GNU" and
>   "Windows-MSVC".  The GNU ABI is for code produced by MinGW
>   toolchains, while the MSVC ABI is for code produced by Microsoft's
>   MSVC compiler (though see the PDB note below), or Clang targeting
>   one of {i686,aarch64,x86_64}-pc-windows-msvc.  The existing
>   "Windows" value continues to work and now means "let GDB pick the
>   flavor": GDB uses the configured default OS ABI (from --target) when
>   that is a Windows flavor, and otherwise assumes the GNU flavor.  For
>   example, --target=x86_64-pc-windows-msvc defaults to the MSVC ABI,
>   and --target=x86_64-w64-mingw32 defaults to GNU ABI.  Similarly for
>   the i686 and AArch64 variants.  See "New targets" entry below.

What happens if you build a GDB with --enable-targets=all and load a
.exe?  Is either ABI preferred over the other?  Would it be possible to
"sniff" what ABI it is, for instance with the presence of some
particular symbol?

Simon
  

On 2026-07-15 02:21, Simon Marchi wrote:
> On 2026-07-14 18:15, Pedro Alves wrote:
>> On 2026-07-14 12:57, Eli Zaretskii wrote:
>> * GDB now distinguishes between the GNU (MinGW) and MSVC Windows ABIs.
>>
>>   The "set osabi" command accepts two new values, "Windows-GNU" and
>>   "Windows-MSVC".  The GNU ABI is for code produced by MinGW
>>   toolchains, while the MSVC ABI is for code produced by Microsoft's
>>   MSVC compiler (though see the PDB note below), or Clang targeting
>>   one of {i686,aarch64,x86_64}-pc-windows-msvc.  The existing
>>   "Windows" value continues to work and now means "let GDB pick the
>>   flavor": GDB uses the configured default OS ABI (from --target) when
>>   that is a Windows flavor, and otherwise assumes the GNU flavor.  For
>>   example, --target=x86_64-pc-windows-msvc defaults to the MSVC ABI,
>>   and --target=x86_64-w64-mingw32 defaults to GNU ABI.  Similarly for
>>   the i686 and AArch64 variants.  See "New targets" entry below.
> 
> What happens if you build a GDB with --enable-targets=all and load a
> .exe?  Is either ABI preferred over the other?  

The preferred one is taken out of --target, defaults to GNU.
--enable-targets=foo,bar,all does not affect it.

> Would it be possible to
> "sniff" what ABI it is, for instance with the presence of some
> particular symbol?
> 
I had thought about this, but decided to leave it for a future improvement.

For Cygwin, we detect whether the inferior links with cygwin1.dll.  That's pretty
reliable, as it is not possible to statically link cygwin1.dll.


For GNU vs MSVC, for C programs, both toolchains link with the same C runtime

$ ldd abi-mingw.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffeeae00000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffeea9a0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffee8660000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffee8450000)
$ ldd abi-windows-msvc.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffeeae00000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffeea9a0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffee8660000)
        apphelp.dll => /c/WINDOWS/SYSTEM32/apphelp.dll (0x7ffee6b20000)

so that angle does not work.


Symbols that I thought could help identify mingw/gnu:

 $ nm -j abi-mingw.exe | sort -u | grep "mingw\|gcc"
 .rdata$.refptr.__mingw_app_type
 .rdata$.refptr.__mingw_initltsdrot_force
 .rdata$.refptr.__mingw_initltsdyn_force
 .rdata$.refptr.__mingw_initltssuo_force
 .refptr.__mingw_app_type
 .refptr.__mingw_initltsdrot_force
 .refptr.__mingw_initltsdyn_force
 .refptr.__mingw_initltssuo_force
 ___w64_mingwthr_add_key_dtor
 ___w64_mingwthr_remove_key_dtor
 __gcc_deregister_frame
 __gcc_register_frame
 __mingw_GetSectionCount
 __mingw_GetSectionForAddress
 __mingw_SEH_signal_dispatcher
 __mingw_TLScallback
 __mingw_app_type
 __mingw_enum_import_library_names
 __mingw_initltsdrot_force
 __mingw_initltsdyn_force
 __mingw_initltssuo_force
 __mingw_invalidParameterHandler
 __mingw_module_is_dll
 __mingw_raise_matherr
 __mingw_setusermatherr
 __mingwthr_cs
 __mingwthr_cs_init

and maybe _pei386_runtime_relocator, though I read recently some discussion about that mechanism
not being needed anymore or something like that.  If we make GNU the default, then this will only
matter for a x86_64-pc-windows-msvc gdb build (and aarch64, etc...), so not that bad, as I expect
such a build to be used to mainly debug windows-msvc programs and libraries.

Symbols that I thought could help identify MSVC ABI could be the unwind entries pointing
to Microsoft's CRT exception handlers:

 __CxxFrameHandler
 __CxxFrameHandler2
 __CxxFrameHandler3
 __CxxFrameHandler4

I tested with clang -fno-exceptions and I still see those, but maybe that's not reliable
and we should look for other symbols.

I only tested with clang so far (not MSVC's cl.exe), though I did notice that
with clang I only see a COFF symbol table if I use "-Wl,/debug:dwarf".

If I let clang emit pdb (the default), then there's no coff table, meaning gdb sees no symbols until we teach
it about pdb.  The fact that the PE has a matching PDB alone I don't think is reliable way in the long term,
since nothing stops gcc/clang targeting mingw from also emitting PDB.  When we're able to read the pdb,
maybe there's some reliable way inside its info.

So in sum, it's possibly doable as an heuristic, but I'd rather do it separately, starting
with the --target default, as it'll take more time and poking to work this all out.  I'm more
interested on laying the foundation to build other things on top of at this point.

Pedro Alves
  

> Date: Tue, 14 Jul 2026 23:15:30 +0100
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> On 2026-07-14 12:57, Eli Zaretskii wrote:
> 
> > This part is okay, but I think it would make sense to tell which
> > compilers produce binaries of Windows-MSVC ABI.  E.g., does the above
> > mean that GDB will now be able to debug programs produces by MSVC,
> > including use of the PDB debug data files?
> > 
> > Also, you only mention the 64-bit host and target triplets, but does
> > that mean this is limited to 64-bit Windows programs?
> 
> That was an example, and the "New targets" section being pointed at has the
> 32-bit x86 and AArch64 triplets.  But I can try to make it clearer, along with
> addressing your other points.
> 
> How about this?

Perfect, thanks.

> > Should we have a cross-reference here to the "Configure Options" node?
> 
> Sounds good.  Added it at the end, like:
> 
>  +the @code{--target} configure option) when that is a Windows flavor,
>  +and otherwise assumes the GNU flavor.  @xref{Configure Options}.

Thanks.

> Below's the full updated patch.

Fine by me, thanks.
  

On 7/15/26 7:18 AM, Pedro Alves wrote:
> On 2026-07-15 02:21, Simon Marchi wrote:
>> On 2026-07-14 18:15, Pedro Alves wrote:
>>> On 2026-07-14 12:57, Eli Zaretskii wrote:
>>> * GDB now distinguishes between the GNU (MinGW) and MSVC Windows ABIs.
>>>
>>>   The "set osabi" command accepts two new values, "Windows-GNU" and
>>>   "Windows-MSVC".  The GNU ABI is for code produced by MinGW
>>>   toolchains, while the MSVC ABI is for code produced by Microsoft's
>>>   MSVC compiler (though see the PDB note below), or Clang targeting
>>>   one of {i686,aarch64,x86_64}-pc-windows-msvc.  The existing
>>>   "Windows" value continues to work and now means "let GDB pick the
>>>   flavor": GDB uses the configured default OS ABI (from --target) when
>>>   that is a Windows flavor, and otherwise assumes the GNU flavor.  For
>>>   example, --target=x86_64-pc-windows-msvc defaults to the MSVC ABI,
>>>   and --target=x86_64-w64-mingw32 defaults to GNU ABI.  Similarly for
>>>   the i686 and AArch64 variants.  See "New targets" entry below.
>>
>> What happens if you build a GDB with --enable-targets=all and load a
>> .exe?  Is either ABI preferred over the other?  
> 
> The preferred one is taken out of --target, defaults to GNU.
> --enable-targets=foo,bar,all does not affect it.

I was thinking when building GDB on Linux (with --target that defaults
to something Linux) with --enable-targets=all, i.e. a typical
development build.  In that case, the --target does not help to choose
an ABI, so the fallback must come from somewhere else.


Simon
  

On 2026-07-15 14:13, Simon Marchi wrote:
> On 7/15/26 7:18 AM, Pedro Alves wrote:
>> On 2026-07-15 02:21, Simon Marchi wrote:
>>> What happens if you build a GDB with --enable-targets=all and load a
>>> .exe?  Is either ABI preferred over the other?  
>>
>> The preferred one is taken out of --target, defaults to GNU.
>> --enable-targets=foo,bar,all does not affect it.
> 
> I was thinking when building GDB on Linux (with --target that defaults
> to something Linux) with --enable-targets=all, i.e. a typical
> development build.  In that case, the --target does not help to choose
> an ABI, so the fallback must come from somewhere else.
> 

Hmm, I _think_ I see what the confusion is.  The logic is:

  "let GDB pick the flavor": GDB uses the configured default OS ABI (from --target) when that is a Windows flavor, and otherwise assumes the GNU flavor."
                                                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


The code that does this is here:

+  /* A generic "Windows" OS ABI means a PE binary whose flavor --
+     GNU (MinGW) or MSVC -- could not be determined.  The osabi
+     sniffers and gdbserver's target description both report the
+     generic "Windows" OS ABI, because neither can tell the two
+     flavors apart from the binary alone.  Resolve it here to a
+     concrete flavor: use the configured default if that is itself a
+     Windows flavor, otherwise assume GNU.  */
+  if (info->osabi == GDB_OSABI_WINDOWS)
+    {
+      info->osabi = GDB_OSABI_WINDOWS_GNU;       <<< "somewhere else"
+#ifdef GDB_OSABI_DEFAULT
+      if (GDB_OSABI_DEFAULT == GDB_OSABI_WINDOWS_GNU
+         || GDB_OSABI_DEFAULT == GDB_OSABI_WINDOWS_MSVC)
+       info->osabi = GDB_OSABI_DEFAULT;
+#endif
+    }

So with --target=Linux, if the sniffer, or the target.xml, or the user picks/returns
GDB_OSABI_WINDOWS, we resolve to GDB_OSABI_WINDOWS_GNU, as GDB_OSABI_DEFAULT itself is not
a Windows flavor (it's GDB_OSABI_LINUX).

Does this clarify it?  The "somewhere else" is basically indicated above in the <<< line.

Pedro Alves
  

On 7/15/26 10:10 AM, Pedro Alves wrote:
> On 2026-07-15 14:13, Simon Marchi wrote:
>> On 7/15/26 7:18 AM, Pedro Alves wrote:
>>> On 2026-07-15 02:21, Simon Marchi wrote:
>>>> What happens if you build a GDB with --enable-targets=all and load a
>>>> .exe?  Is either ABI preferred over the other?  
>>>
>>> The preferred one is taken out of --target, defaults to GNU.
>>> --enable-targets=foo,bar,all does not affect it.
>>
>> I was thinking when building GDB on Linux (with --target that defaults
>> to something Linux) with --enable-targets=all, i.e. a typical
>> development build.  In that case, the --target does not help to choose
>> an ABI, so the fallback must come from somewhere else.
>>
> 
> Hmm, I _think_ I see what the confusion is.  The logic is:
> 
>   "let GDB pick the flavor": GDB uses the configured default OS ABI (from --target) when that is a Windows flavor, and otherwise assumes the GNU flavor."
>                                                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 
> The code that does this is here:
> 
> +  /* A generic "Windows" OS ABI means a PE binary whose flavor --
> +     GNU (MinGW) or MSVC -- could not be determined.  The osabi
> +     sniffers and gdbserver's target description both report the
> +     generic "Windows" OS ABI, because neither can tell the two
> +     flavors apart from the binary alone.  Resolve it here to a
> +     concrete flavor: use the configured default if that is itself a
> +     Windows flavor, otherwise assume GNU.  */
> +  if (info->osabi == GDB_OSABI_WINDOWS)
> +    {
> +      info->osabi = GDB_OSABI_WINDOWS_GNU;       <<< "somewhere else"
> +#ifdef GDB_OSABI_DEFAULT
> +      if (GDB_OSABI_DEFAULT == GDB_OSABI_WINDOWS_GNU
> +         || GDB_OSABI_DEFAULT == GDB_OSABI_WINDOWS_MSVC)
> +       info->osabi = GDB_OSABI_DEFAULT;
> +#endif
> +    }
> 
> So with --target=Linux, if the sniffer, or the target.xml, or the user picks/returns
> GDB_OSABI_WINDOWS, we resolve to GDB_OSABI_WINDOWS_GNU, as GDB_OSABI_DEFAULT itself is not
> a Windows flavor (it's GDB_OSABI_LINUX).
> 
> Does this clarify it?  The "somewhere else" is basically indicated above in the <<< line.

Ah yes thanks, I had missed the "and otherwise assumes the GNU flavor".

Simon