[PATCH 0/4] Support the Windows/MSVC target in GDB

[PATCH 0/4] Support the Windows/MSVC target in GDB

[Pedro Alves]

This series teaches GDB about Windows targets whose triplet uses the
"windows" OS, as produced by Clang (e.g. x86_64-pc-windows-msvc), and
about the MSVC ABI those targets use.

The motivation is to be able to build a MinGW-hosted GDB that defaults
to debugging MSVC-ABI binaries, and to run the testsuite with such a
GDB and a matching Clang.  IOW, to build GDB with:

 --host=x86_64-w64-mingw32 --target=x86_64-pc-windows-msvc

To be clear, this does _not_ propose making it possible to build GDB
with --host=x86_64-pc-windows-msvc.  That's a different can of worms.

This will let us use "istarget *-*-windows-msvc" in the testsuite
where we need to distinguish MinGW and MSVC environments.

The MSVC ABI is not the same as the GNU (MinGW) ABI -- they differ in
long double, in the C++ ABI, and in other details.  So the series also
splits GDB's single "Windows" OS ABI into two flavors, GNU and MSVC,
picks the right default based on how GDB was configured, and fixes a
concrete ABI difference (long double) as simple example.

Another way to handle the ABI split would be to keep the single
"Windows" osabi, and add a new "set windows-abi gnu/msvc" switch,
similar to "set cp-abi", and also, arch-specific abi settings like
"set arm abi auto/APCS/AAPCS", and "set powerpc vector-abi", etc.  I
didn't go for that approach because the MSVC/GNU ABI split is a lot
deeper than those other ABI switches: affects C ABI (long double),
calling conventions, headers and libraries linked with, C++ ABI,
mangling scheme, and on and on, basically almost like a separate
target.  While OTOH, "set arm abi" etc. are more about multilibs for a
single target, they normally come from the same sources (I mean,
toolchain/runtime project), just compiled differently, with some
compiler option.  OTOH, it is possible to mix GNU and MSVC code in the
same binary (and it happens all the time, given system DLLs are built
with MSVC), so maybe that distinction isn't that important.  OTOOH,
what would this mean for the Cygwin osabi?

The first two patches (recognize *-*-windows* and treat as native) are
independent of this, and could go in even if the design of this part
changes.  So I figured I'd send what I have right now for comments.

This series depends on the BFD patch:

  bfd: recognize *-*-windows* Windows targets

which was sent separately to the binutils list, here:

  https://inbox.sourceware.org/binutils/20260713231552.1303239-1-pedro@palves.net/T/

I have a follow-up series that starts teaching the testsuite about
windows-msvc, too.  I've done just enough to be able to validate the
idea, and see a few testcases pass.

Pedro Alves (4):
  gdb: recognize *-*-windows* Windows targets
  gdb: treat Windows host + Windows target as native
  gdb: distinguish GNU and MSVC flavors of the Windows OS ABI
  gdb: MSVC "long double" is a 64-bit double

 gdb/NEWS                   | 16 ++++++++++++++++
 gdb/aarch64-windows-tdep.c |  5 ++++-
 gdb/amd64-windows-tdep.c   |  6 +++++-
 gdb/arch-utils.c           | 18 ++++++++++++++++++
 gdb/configure              | 19 +++++++++++++++++--
 gdb/configure.ac           | 19 +++++++++++++++++--
 gdb/configure.tgt          | 22 +++++++++++-----------
 gdb/doc/gdb.texinfo        | 15 +++++++++++++++
 gdb/i386-windows-tdep.c    |  6 +++++-
 gdb/osabi.c                | 32 +++++++++++++++++++++++++++-----
 gdb/osabi.h                |  8 ++++++++
 gdb/windows-tdep.c         |  9 +++++++++
 gdb/windows-tdep.h         |  5 +++--
 gdbsupport/osabi.def       |  2 ++
 14 files changed, 157 insertions(+), 25 deletions(-)


base-commit: 490469846dcef89fe53668bdbba73591c64bed61
-- 
2.54.0

[PATCH 1/4] gdb: recognize *-*-windows* Windows targets

[Pedro Alves]

Clang's default target on Windows uses the "windows-msvc" OS in its
triplet, e.g. x86_64-pc-windows-msvc, i686-pc-windows-msvc, and
aarch64-pc-windows-msvc.  This is different from MinGW triplets -- it
means that the compiler produces binaries following the Windows/MSVC
ABI, not the GNU ABI.

config.sub already canonicalizes these, but gdb/configure.tgt has no
entry for the "windows" OS.  Configuring GDB for such a target does
not fail.  The per-CPU section of configure.tgt still matches on the
CPU, so gdb_target_obs is non-empty and the "configuration ... is
unsupported" check does not trigger, but the resulting GDB has no
Windows support at all -- none of the windows-tdep.o and friends are
pulled in, and no Windows OS ABI is selected.

Fix this my extending the i386, x86_64 and aarch64 Windows entries to
also match "*-windows*", and map the "windows" OS to
GDB_OSABI_WINDOWS, so that Windows target triplets spelled with the
"windows" OS select the same target objects and OS ABI as their MinGW
counterparts.

The GNU/MinGW and MSVC ABIs are not actually identical (long double,
the C++ ABI, and so on differ), so a later commit will introduce a
distinct OS ABI for the MSVC case.  For now, reusing GDB_OSABI_WINDOWS
is enough to make these configurations build.

Note: even though config.sub does not support "windows-gnu" today,
Clang and Rust support it, as an alias for MinGW.  Clang also accepts
plain "windows", treating it as MSVC.  That's why the patch matches
"windows*".  Also, this is what is already used in bfd, anyhow:

 bfd/configure.host:81:*-*-windows*)
 bfd/acinclude.m4:24:*-*-msdos* | *-*-go32* | *-*-mingw32* | *-*-cygwin* | *-*-windows*)
 ...

Change-Id: I14a0030efc388ae3dc5f34b2580849c41219e2bd
---
 gdb/configure.tgt | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/gdb/configure.tgt b/gdb/configure.tgt
index 362de60065c..f473f67d8bd 100644
--- a/gdb/configure.tgt
+++ b/gdb/configure.tgt
@@ -155,8 +155,8 @@ aarch64*-*-linux*)
 			symfile-mem.o linux-record.o"
 	;;
 
-aarch64-*-mingw*)
-        # Target: MingW/aarch64
+aarch64-*-mingw* | aarch64-*-windows*)
+        # Target: Windows/aarch64
 	gdb_target_obs="aarch64-windows-tdep.o windows-tdep.o"
         ;;
 
@@ -339,11 +339,7 @@ i[34567]86-*-gnu*)
 	# Target: Intel 386 running the GNU Hurd
 	gdb_target_obs="i386-gnu-tdep.o glibc-tdep.o solib-svr4.o"
 	;;
-i[34567]86-*-cygwin*)
-	# Target: Intel 386 running win32
-	gdb_target_obs="i386-windows-tdep.o windows-tdep.o"
-	;;
-i[34567]86-*-mingw32*)
+i[34567]86-*-cygwin* | i[34567]86-*-mingw32* | i[34567]86-*-windows*)
 	# Target: Intel 386 running win32
 	gdb_target_obs="i386-windows-tdep.o windows-tdep.o"
 	;;
@@ -739,8 +735,8 @@ x86_64-*-freebsd* | x86_64-*-kfreebsd*-gnu)
 	gdb_target_obs="amd64-fbsd-tdep.o ${i386_tobjs} \
 			i386-bsd-tdep.o i386-fbsd-tdep.o"
 	;;
-x86_64-*-mingw* | x86_64-*-cygwin*)
-        # Target: MingW/amd64
+x86_64-*-mingw* | x86_64-*-cygwin* | x86_64-*-windows*)
+        # Target: Windows/amd64
 	gdb_target_obs="amd64-windows-tdep.o \
                         ${i386_tobjs} i386-windows-tdep.o \
                         windows-tdep.o"
@@ -826,7 +822,7 @@ m68*-*-openbsd* | m88*-*-openbsd* | vax-*-openbsd*) ;;
 *-*-*-gnu*)	;; # prevent non-GNU kernels to match the Hurd rule below
 *-*-gnu*)	gdb_osabi=GDB_OSABI_HURD ;;
 *-*-mingw32ce*)	gdb_osabi=GDB_OSABI_WINCE ;;
-*-*-mingw*)	gdb_osabi=GDB_OSABI_WINDOWS ;;
+*-*-mingw* | *-*-windows*)	gdb_osabi=GDB_OSABI_WINDOWS ;;
 *-*-cygwin*)	gdb_osabi=GDB_OSABI_CYGWIN ;;
 *-*-dicos*)	gdb_osabi=GDB_OSABI_DICOS ;;
 powerpc-*-aix* | rs6000-*-* | powerpc64-*-aix*)
-- 
2.54.0

[PATCH 2/4] gdb: treat Windows host + Windows target as native

[Pedro Alves]

Configuring GDB with:

  --host=x86_64-w64-mingw32
  --target=x86_64-pc-windows-msvc

currently results in a cross- or remote-only debugger, with the
Windows native-debug support (windows-nat.o and friends) left out.

This is because gdb/configure currently decides whether GDB is a
native debugger by comparing the host and target triplets for exact
equality:

  if test "${target}" = "${host}"; then
    gdb_native=yes
  else
    gdb_native=no
  fi

That is too strict on Windows.  A GDB built on mingw (host
x86_64-w64-mingw32) that targets binaries produced by a compiler
defaulting to the MSVC ABI (target x86_64-pc-windows-msvc) debugs
processes running on the same machine, so it is native, even though
the two triplets differ in vendor and OS.  With the strict check such
a configuration ends up with gdb_native=no, and configure.nat is not
sourced, and the Windows native-debug support is left out.

Fix this by relaxing the check -- in addition to the exact-match case,
treat the configuration as native when the host and target CPUs match
and both host and target are Windows systems.  Requiring the CPUs to
match makes it so that cross-CPU configurations such as an aarch64
host with an x86_64 target continue to be non-native.

Change-Id: I7f92436b7978b65aec6ba404bc8f7bbb954326f7
---
 gdb/configure    | 19 +++++++++++++++++--
 gdb/configure.ac | 19 +++++++++++++++++--
 2 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/gdb/configure b/gdb/configure
index 3733ef76948..45145a00b63 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -25218,10 +25218,25 @@ CPPFLAGS=$OLD_CPPFLAGS
 # configuration.
 gdb_host_obs=posix-hdep.o
 
+# Check whether the configuration is native -- i.e., whether GDB will
+# debug processes running on the same machine it runs on.  If so, we
+# let configure.host and configure.nat pull in the native-debug
+# support.
+gdb_native=no
 if test "${target}" = "${host}"; then
   gdb_native=yes
-else
-  gdb_native=no
+elif test "${host_cpu}" = "${target_cpu}"; then
+  # Debugging Windows binaries on a Windows host is native even when
+  # the host and target triplets differ across the mingw/cygwin/msvc
+  # ABI boundary.  E.g., a mingw32-hosted GDB targeting binaries
+  # produced by a compiler defaulting to windows-msvc.
+  case ${host_os} in
+    mingw* | cygwin*)
+      case ${target_os} in
+	mingw* | cygwin* | windows*)
+	  gdb_native=yes ;;
+      esac ;;
+  esac
 fi
 
 . $srcdir/configure.host
diff --git a/gdb/configure.ac b/gdb/configure.ac
index 5296d76f2cf..5d71e2bf1a4 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -222,10 +222,25 @@ BFD_64_BIT
 # configuration.
 gdb_host_obs=posix-hdep.o
 
+# Check whether the configuration is native -- i.e., whether GDB will
+# debug processes running on the same machine it runs on.  If so, we
+# let configure.host and configure.nat pull in the native-debug
+# support.
+gdb_native=no
 if test "${target}" = "${host}"; then
   gdb_native=yes
-else
-  gdb_native=no
+elif test "${host_cpu}" = "${target_cpu}"; then
+  # Debugging Windows binaries on a Windows host is native even when
+  # the host and target triplets differ across the mingw/cygwin/msvc
+  # ABI boundary.  E.g., a mingw32-hosted GDB targeting binaries
+  # produced by a compiler defaulting to windows-msvc.
+  case ${host_os} in
+    mingw* | cygwin*)
+      case ${target_os} in
+	mingw* | cygwin* | windows*)
+	  gdb_native=yes ;;
+      esac ;;
+  esac
 fi
 
 . $srcdir/configure.host
-- 
2.54.0

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

[Pedro Alves]

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(-)

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.
+
 * 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 +138,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..0ca1b37fe57 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.
+
 @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)
-- 
2.54.0

[PATCH 4/4] gdb: MSVC "long double" is a 64-bit double

[Pedro Alves]

The GNU (MinGW) and MSVC ABIs disagree on "long double".

- GCC the 80-bit x87 extended type on x86 (stored in 96 bits on i386
  and 128 bits on amd64), and the 128-bit IEEE quad on AArch64.

- MSVC makes "long double" just an alias for "double", an IEEE 64-bit
  double.

GDB modeled only the GNU sizes, via the per-architecture defaults, so
with an MSVC program it got "long double" wrong.  E.g. on AMD64:

 (gdb) set osabi Windows-MSVC
 (gdb) print sizeof (long double)
 $1 = 16

when an MSVC "long double" should be 8 bytes.

Now that we can distinguish the GNU and MSVC flavors, set the smaller
size and IEEE-double format for the MSVC flavor.  This is done in the
shared windows_init_abi, so it covers i386, amd64 and AArch64 all at
once.

After:

 (gdb) set osabi Windows-MSVC
 (gdb) print sizeof (long double)
 $1 = 8

Change-Id: I0acb2e80027cb7b1fcfd1f39dd050a24438e1662
---
 gdb/windows-tdep.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
index 78bf49b9c81..a1e44f8aa3f 100644
--- a/gdb/windows-tdep.c
+++ b/gdb/windows-tdep.c
@@ -17,6 +17,7 @@
 
 #include "windows-tdep.h"
 #include "extract-store-integer.h"
+#include "gdbtypes.h"
 #include "gdbsupport/gdb_obstack.h"
 #include "xml-support.h"
 #include "gdbarch.h"
@@ -1031,6 +1032,14 @@ windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
   /* On Windows, "long"s are only 32bit.  */
   set_gdbarch_long_bit (gdbarch, 32);
 
+  /* With the MSVC ABI, "long double" is just an IEEE 64-bit double,
+     the same as "double".  */
+  if (info.osabi == GDB_OSABI_WINDOWS_MSVC)
+    {
+      set_gdbarch_long_double_bit (gdbarch, 64);
+      set_gdbarch_long_double_format (gdbarch, floatformats_ieee_double);
+    }
+
   /* Enable TLS support.  */
   set_gdbarch_fetch_tls_load_module_address (gdbarch,
 					     windows_tls_index_address);
-- 
2.54.0

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

[Eli Zaretskii]

> 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>

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

[Pedro Alves]

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
-- 
2.54.0

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

[Simon Marchi]

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

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

[Pedro Alves]

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

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

[Eli Zaretskii]

> 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.

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

[Simon Marchi]

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

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

[Pedro Alves]

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

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

[Simon Marchi]

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