From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MULIKbtsV2p9twkAWB0awg (envelope-from ) for ; Wed, 15 Jul 2026 07:19:23 -0400 Received: by simark.ca (Postfix, from userid 112) id A577F1E09E; Wed, 15 Jul 2026 07:19:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 274F31E099 for ; Wed, 15 Jul 2026 07:19:23 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7AD0C4BA2E32 for ; Wed, 15 Jul 2026 11:19:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7AD0C4BA2E32 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by sourceware.org (Postfix) with ESMTPS id B3B9B4BA2E04 for ; Wed, 15 Jul 2026 11:18:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B3B9B4BA2E04 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B3B9B4BA2E04 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.128.41 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784114336; cv=none; b=nXzv4+bC1/QUy2GPa7YSCWGak8b1mu/d94k5J1ivJgvTP7kHvnnDpiPNH4uZAmhkiMaImNmATCIg2ODDh+MmM456EULtE9Ec0vTG3JJwk8tzd8EvaUUdVNSfoy7E4a9j4D2FuPdDCqYAFIg2J7drYvZ1Q/hnTn/CvYaSnygWvoE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784114336; c=relaxed/simple; bh=i3i6EgXy2KcLU9Eo+KzD41zwsvayy3Yl/BCveGXeq5I=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=cwQVn/BTSk7wsVqz+1evGO9OXliN3evkTzGdJ/AKHHecPXE1hyBjPU7P3xAUSE0Z4gu558JhWJ1nnTowWqzfej3XJ+0OKOp0sQDGjLA4vGDAHfVhnayYWAENfSsMaIm9ND2NBcuICmgpuNdph1b7Sys+YiOuvnZvJg9OJjdCNgA= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B3B9B4BA2E04 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-493e497643fso9546735e9.0 for ; Wed, 15 Jul 2026 04:18:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784114335; x=1784719135; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4l0yBPDDHquvd6LL4TumeI3aOq8FpBAxNwWkEv1Jc+o=; b=TzyPvrE2O9h5CCo9eAzWue4mdSHaeMvWQlU4JHPxLWnahMBmPM/+fau3ve3PoYGwwp sIyrVDmIfH/U33obgGxuc+2mu5BV6oC3pvk0F+3wGwYh1Riew9+/GJTsNtzufLbSc+8A yeRsChxhTjf78AbxDK/GEfUYFGznStRkdl8KgH3j2iXfKH2e9/Th7PbVRaCq/JMRcnr8 /sW1oU32FOCfmPluUlo33M5U1m24C30eHwDJjdmKPVDE+7a4zAzuR+lYRGv7efgZPDNG 2hs1efhzKeoBiSN/CIZutsvWluBxpWbdBrG0qfyTdozwGgo1EWVTTc//5KFWAWJIzeeB rZyQ== X-Gm-Message-State: AOJu0YxXZ1iUfdhfpHrXLpfwP0de5TlZCzUhKij/5brM44fq2h0pjQPH enVBb/I1sJTkVLCuXtEt5nwjZxMRGYid9e2wQZ4Kk7K6QefG+HnJsk05 X-Gm-Gg: AfdE7cnt/PtPzqAkUfzhL2pFdF/1azyynxxQq3zIJZ3g38IT8v0iuYs5B7RSuU8Lcj+ TTK5tysg2zHLXcftbUgoauwkNHFkzsAAdLdZ8gKJSzfUN6Hmk3Z2PiYIcBKgungIniCVNuqJiVT ksr1TzuXS1pZGWPRcFbuguCPfiCh7mkNe1ksVWFoNzhze7cTA/7/j07Q8HZwXaa9xAD3vHZLy6I Xf2G+an2iIw3WKXKxDLAeoPjqImDSGcXBou4DKNzdFYs0qnfNKNHUmbBaM0s1UDQ30Z753Wdaq6 ahobgcV0UNt1W7Vc54RwyUnTrOFYQYAWVF8NTQgN+HXwmbwqGpgz3M5KMhp7bJp3hnmgi8unf4W NhWTDI7PIBh7Ts7xCC2RW13gApE4vLSkML+az5MxG1TgKqZZXivxhJfwVBjLHwJetkQDUsZeKbF VHdNyvHQfvaqMFQS3LcnEYUPqhWua6K0Mk1B0ZtxtlIlro9dZYyuL6Mic= X-Received: by 2002:a05:600c:3e19:b0:493:f28e:462a with SMTP id 5b1f17b1804b1-493f87e6ba2mr182237835e9.12.1784114335248; Wed, 15 Jul 2026 04:18:55 -0700 (PDT) Received: from ?IPV6:2001:8a0:fae3:3700:c002:a046:220c:1c27? ([2001:8a0:fae3:3700:c002:a046:220c:1c27]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4953c5a4c0csm33508535e9.0.2026.07.15.04.18.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jul 2026 04:18:54 -0700 (PDT) Message-ID: Date: Wed, 15 Jul 2026 12:18:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] gdb: distinguish GNU and MSVC flavors of the Windows OS ABI To: Simon Marchi , Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20260714004507.1323332-1-pedro@palves.net> <20260714004507.1323332-4-pedro@palves.net> <86ik6hg4vu.fsf@gnu.org> <2c36a069-53ed-465f-8ecf-360cc272eaac@palves.net> <4953c47d-3904-4df4-945b-4693c2df9dad@simark.ca> From: Pedro Alves Content-Language: en-US In-Reply-To: <4953c47d-3904-4df4-945b-4693c2df9dad@simark.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org 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