[PATCH] bfd: recognize *-*-windows* Windows targets

[Pedro Alves]

Hi Jan,

Thanks for the quick review.

On 2026-07-14 07:05, Jan Beulich wrote:
> On 14.07.2026 01:15, Pedro Alves wrote:
>> 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.
> 
> Doesn't this mean that ...
> 
>>  config.sub already canonicalizes these, but
>> config.bfd doesn't map them to a BFD target vector, so configuring for
>> one of these targets fails to select a default vector.
>>
>> Fix this by extending the i386, x86_64 and aarch64 PE entries to also
>> match "*-windows*", so that Windows targets spelled with the "windows"
>> OS select the same PE vectors as their mingw counterparts.
> 
> ... this and ...
> 
>> 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:
> 
> ... this is wrong, in meaning "GNU ABI" in all cases?

For BFD, as a target (not host), GNU or MSVC ABI (or even Cygwin) doesn't matter,
it's still PE/COFF files.  All these Windows variants pick up the same bfd vectors.

So far, I've been using GDB (and thus bfd) targeting mingw to debug MSVC ABI
binaries, and running the GDB testsuite with that, and it works fine, but that's
a hack, as it leaves no way for the GDB testsuite do use something like
'istarget "*-*-windows-msvc"' to distinguish from mingw in the cases where
that is needed: around compiler/tool invocation, which headers and libraries
are available; not really about GDB features, which are all the same.

So this patch let's us move in the non-hacky direction.

If at some point in the future, someone finds a need to have config.bfd care about
distinguishing "windows-msvc" from "windows-gnu", then it's trivial to do that
with a new "windows | windows-msvc" match above the current one.  But I don't see a
need currently.

> 
> Further, while in the follow-on mail you say this aiming at gdb, what
> about in particular ld? If ld is deliberately not covered, wouldn't
> top-level configury then want to gain a noconfigdirs adjustment, such
> that ld (and perhaps also other components) won't even be tried to be
> configured?

ld currently gets:

 *** ld does not support target x86_64-pc-windows-msvc
 *** see ld/configure.tgt for supported targets

I myself configure with --disable-ld, etc. as (for this target) I want
to use gdb against clang + lld-link.

If someone wants to tweak that, by all means.  Ideally it'd be done by
top level consulting ld's configure.tgt, like done for libatomic, etc.
instead of hard coding at the top level.  But I don't think this bfd change
should be blocked by that, as it has zero impact on ld, it simply continues
working the way it has.

Pedro Alves