Re: GDB 12.0.90 available for testing

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 8 Apr 2022 15:44:53 +0100
> Cc: aburgess@redhat.com, gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> On 2022-04-01 15:31, Joel Brobecker wrote:
> >>> I don't know how to answer that question. Is that something
> >>> I can figure out from looking at how we configure the build
> >>> of MinGW-w64?
> >>
> >> It's enough (and simpler) to look at the DLLs on which the GDB
> >> executable on Windows depends, with this command:
> >>
> >>   objdump -x gdb.exe | fgrep "DLL Name"
> > 
> > Thanks for the tip. Here's what I have:
> > 
> >     | $ objdump.exe -x gdb.exe | grep "DLL Name"
> >     | 	DLL Name: python39.dll
> >     | 	DLL Name: ADVAPI32.dll
> >     | 	DLL Name: KERNEL32.dll
> >     | 	DLL Name: msvcrt.dll
> >     | 	DLL Name: USER32.dll
> >     | 	DLL Name: WS2_32.dll
> > 
> > 
> >> Note the two instances of msvcrt.dll -- this is the (traditional) MS C
> >> runtime library.  If you see UCRT instead, it might explain the
> >> difference in our observations.
> > 
> > No luck with that lead, it seems...
> > 
> 
> Since Hannes is able to reproduce this with a small program outside GDB,
> I'd suspect this could be related to either:
> 
>  - Windows version.  Hannes mentioned Windows 7.  I don't think we heard Windows
>    versions from others.
> 
>  - Which console / terminal is used.  E.g., cmd.exe in a standard Windows console,
>    Powershell, cygwin/msys2 bash, Windows SSH, etc.

Perhaps Joel could try that test program in his environment and see if
it produces the same behavior.  If he sees something different, we
could compare the Windows versions.

As for the shell: the problem happens only for direct connection to
the console device, which means cmd.exe, not Bash which runs via
mintty etc., which AFAIK basically appears as a pipe to the console
applications.