From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 82/3Fs/QYGpBZyUAWB0awg (envelope-from ) for ; Wed, 22 Jul 2026 10:16:47 -0400 Received: by simark.ca (Postfix, from userid 112) id 337E61E099; Wed, 22 Jul 2026 10:16:47 -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=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 F070F1E099 for ; Wed, 22 Jul 2026 10:16:45 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0A45B4BA23D6 for ; Wed, 22 Jul 2026 14:16:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0A45B4BA23D6 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id 179E24BA2E25 for ; Wed, 22 Jul 2026 14:16:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 179E24BA2E25 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 179E24BA2E25 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784729780; cv=none; b=rVDx/8mH7rMYk/dV3hfXdYi+h3NydmtLCOXAEDtKhOB+kMwvWwxhen/veq8iOijREjjyd6vv4hYPVPuHzWoYbtmaL+1d9u/tq2TbTBJdz4J3S57LylN9E9gKpmIm1xcNkCxNnt5hUmggjZ/lBd9/sfdTh7JyPKHAzwjzoxPZxps= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784729780; c=relaxed/simple; bh=2GJeTQsaF5vjwyoeVw+MKSV1+72Jf/shUJB/QMcuGo0=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=NzrVOcN567eCMeel+xEcSf5/5oA1VWKzz04FirY1Yo+cvcISr7qVnKUmdhZ9pUD+ibGfhTkm9UBDiKWBeKmDtjB9e41R62KbnzKTo/rQvBSC8utEZKWDXol2fsB8rhk0t/FhmfuwJFD6HxnhXDUvo3TnsM18Vpx3cG0VTBljT6I= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 179E24BA2E25 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4955aa106b1so32286225e9.0 for ; Wed, 22 Jul 2026 07:16:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784729779; x=1785334579; 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=4HIX8zFitGvoKaxrcGcI4eNzNbHpCwwIm8ObvwuMDeY=; b=OmPz2UPC3itaelgUBAGxV8KKa2jE8RxAI27fvEOyxCtGRk4lEFiiB0i/ANRJNqK9h3 SS9hxPjTZfLwYGEx6Z5ZsEN+ZZV3v3MQInJ0a+6t9ekeJqqfp8x2tS6+lM+D/V68Z3cg kayNLT3Agcwuto/r5KrPqcruUvFdCH2mrAQq5Rw4k/OJ0FkLegm1dvyeoz73tSarUTik l6sgdSBQ9k7GTIxtt0u7q+ppxedjLuDTllh9t6htqqAzRtCL401Y3CqVO2IVFfex+zgK cA7hYoDgj08kNX6p1w2Pv3DJJqDNKxve5aqA5gUvLAxuT/NbBDupxwRAkkRqjja1jc0y Pulw== X-Gm-Message-State: AOJu0YxBAVrMMQvruUCGZKpqLEpRXuSUFgvIB4H/0LGqv25d5DcwVVkD a9K0bvXL4hwJkNVhm1ZVHRyUV0gTe+K2yg+CvQHOXl8xhxqkEVyHh7llAlJP+p1T X-Gm-Gg: AR+sD11fzEWTNH7hJ+ZAez4yvtB9CsqpnRDdu3wxRH7pO4BPgmwax4Bko9f/G9bC1RI pqh+bdqRk677KMYJQnUhInVLJKXJvDFK/aqHKPZYqSyQSfo/ImNGO+VeTS3inznV6pFdZ8xpQuo jj28GBC/D+XRuCceJYVRjssH099+StAtIITWHMAKhUxmp+6QPOGWdYJyWXK2643vAoN7ou9lOi8 b6ZClcAD5jHP2CSIcmW/8BTnXfmpVjNfLbLubax+/rgHeFh8+ehaFG8bNW4Xplu2St3YiEeKdog gJXDAcQvH8pVJiPHNOOMRJfMligZtCld20+aMyycaw60ZlIZlUUnlCd/np3mrBAYJG9DDgeT/wz ogEFfCtrOHukEvF0UX7cdETxv7ueR61RZ0/Q5uTfc3JR5Sb4c7QWRx+axH9nFVAei6bnW37+jD2 S4roUWybrPtWUjbcpJIq5/7VG4vK/LCGjRY/A0jKmJvtZieUU87ondDSA= X-Received: by 2002:a05:600c:3b9c:b0:493:e57e:7aa5 with SMTP id 5b1f17b1804b1-4954dff444bmr268070855e9.22.1784729778463; Wed, 22 Jul 2026 07:16:18 -0700 (PDT) Received: from ?IPV6:2001:8a0:fae3:3700:29ae:9c1e:45d9:1a25? ([2001:8a0:fae3:3700:29ae:9c1e:45d9:1a25]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-495653d38dbsm140777565e9.15.2026.07.22.07.16.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jul 2026 07:16:18 -0700 (PDT) Message-ID: Date: Wed, 22 Jul 2026 15:16:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/Windows testsuite: Embed asInvoker manifest in test executables To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20260709174351.431907-1-pedro@palves.net> <86zezzjucz.fsf@gnu.org> <17aacd11-cc42-43eb-8328-bdcedcc0dfb5@palves.net> <86ldbijbyr.fsf@gnu.org> From: Pedro Alves Content-Language: en-US In-Reply-To: <86ldbijbyr.fsf@gnu.org> 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 Hi! On 2026-07-11 07:07, Eli Zaretskii wrote: >> Date: Fri, 10 Jul 2026 19:59:17 +0100 >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> >> It's curious that you bring up patch.exe. In the downstream testcase >> I mention, the initial comment that I wrote there mentioned "patch" as "bad" >> word too (as some docs somewhere mention it), and then after the initial fix, >> I noticed that "patch" is actually OK, and so I dropped it from the comment >> in a follow up patch. > > It used to be a problem in some older builds of Windows 11 (and nasty > one not even a manifest could work around it), but ceased to be a > problem a few system updates ago. I have no idea what is the > situation on Windows 10, though. > >> $ mv update.exe patch.exe >> $ ./patch.exe >> Hello! >> >> So looks like Microsoft decided that "patch" wasn't a bad word after all >> at some point more recently... > > Yes. > But do we want to rely on the test suite being run only on the > latest builds of Windows? Right. I meant more like, I thought that the docs I had found were wrong, and that "patch" had never been forbidden. But from your explanations, I now understand that is instead that Microsoft started allowing "patch" more recently. > >> Also, I noticed that executables produced by the GCC 16 that comes with >> MSYS2 do not have the issue. (??!) Digging a bit, it turns out that both MSYS2 and >> Cygwin ship a default-manifest.o object file that GCC pulls in via a spec file. >> This default-manifest.o file is in a separate optional package, which may be >> removed, and GCC keeps working, just won't link in the default manifest. >> >> https://gcc.gnu.org/legacy-ml/gcc-patches/2014-04/msg01378.html >> https://sourceforge.net/p/mingw-w64/wiki2/default_manifest/ > > Thanks, that's good to know. > >> Find below the new patch adding a manifest to every executable in the testsuite. WDYT of this one? > > LGTM. Thanks, I merged it. > >> + # Embed our manifest file. Pass it in Windows-native form. >> + # MSYS2's argument conversion treats a "/foo:/bar" argument as a >> + # colon-separated list of POSIX paths and mistakenly rewrites it >> + # to a semicolon-separated list of Windows paths. E.g.: >> + # >> + # "/manifestinput:/c/gdb/.../windows.manifest" >> + # => >> + # "C:\msys64\manifestinput;C:\gdb\...\windows.manifest" >> + # >> + # I.e., the flag name itself gets converted as if it were a path, >> + # and the ":" becomes ";". >> + # >> + # What triggers the conversion is the value after the colon looking >> + # like an absolute POSIX path (a leading "/"). "/manifest:embed" >> + # above is left alone because "embed" doesn't. Passing the value >> + # as a native "C:/..." path likewise avoids it. >> + set manifest [host_file_normalize ${srcdir}/lib/windows.manifest] >> + lappend ldflags ldflags=-Wl,/manifestinput:${manifest} > > IME, you can work around this incorrect conversion by setting > MSYS_NO_PATHCONV=1. That doesn't help here -- we do want the unix -> windows conversion to happen for all filename arguments, like in "gcc /c/foo.c -o /c/foo.o". Setting MSYS_NO_PATHCONV=1 would break all those. msys2 also allows disabling conversion for one specific argument by using double slash, like //option instead of /option, but here in this case the slash does not appear at the front of the argument, it's after -Wl, so it doesn't work, as it is the compiler that calls the linker, and the compiler is always native windows, doesn't invoke the linker via msys2/bash. An in any case, if it worked, then we'd be stopping the conversion for /manifestinput _and_ the manifest path (the ${manifest} var) at the same time, as it's all part of the same option split by ":", so we'd have to do the manual conversion anyhow. Just like the patch is already doing.