Re: [PATCH] gdb/Windows testsuite: Embed asInvoker manifest in test executables

Hi!

On 2026-07-11 07:07, Eli Zaretskii wrote:
>> Date: Fri, 10 Jul 2026 19:59:17 +0100
>> Cc: [email protected]
>> From: Pedro Alves <[email protected]>
>>
>> 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.