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

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