Re: gdb fails to flush output (msys2)

[Eli Zaretskii]

> From: Juan José García-Ripoll
>  <juanjose.garciaripoll@gmail.com>
> Date: Mon, 14 Mar 2022 18:55:55 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> I am trying to debug some programs on Windows using MSYS2.
> >
> > What do you mean by "using MSYS2" here?
> 
> MSYS2 is the open source software distribution that replaces cygwin in
> providing a unix-like experience in Windows. I am using MSYS2 and the
> Mingw64, UCRT64 and Clang-based toolchains to develop, compile and now
> debug software.

Yes, I know what MSYS2 is.  I asked a more specific question: what
does it mean to debug a program using MSYS2, and how is it different
from debugging a program "normally", e.g. from the MS-Windows Command
Prompt window?  IOW, what MSYS2-specific aspects are involved in this
debugging?

Also, where did you get the GDB binary distribution you are using?

> 
> >> In doing so, I noticed that the gdb mode is not working well with
> >> the output from the debugger.
> >
> > By "gdb mode", do you mean the result of "M-x gdb", followed by
> > specifying the GDB command line to debug a program?  If so, what was
> > the GDB command line you used?
> 
> Yes, as stated in my script, I invoke Emacs's "gdb" function
> programatically supplying it with a command line that is essentially
> "c:/msys64/ucrt64/bin/gdb.exe -i=mi /path/to/my.exe" I have also tried
> invoking it interactively with similar success. The script I provided is
> a bit more clear in the choice of system and paths.
> 
> > What happens if you manually add "C:/msys64/ucrt64/bin" to PATH
> > outside of Emacs, and then invoke GDB from the Windows Command Prompt
> > window to debug that same program -- does that work as expected?
> 
> I prefer not to add MSYS2 + Mingw/Ucrt64 to the path because it collides
> with various tools and because I want to be able to use different
> toolchains, which does not work if I set the path to point to those
> environments (this is what project-cmake automates)

You can do that in a separate Command Prompt window you open, setting
PATH from the shell prompt.  Then the rest of the system will not be
affected by that.

> This said, another way to reproduce this issue is to open a
> Mingw64/Ucrt64 native console, launch emacs from that console and invoke
> M-x gdb.

How do you start the "Mingw64/Ucrt64 native console"?  I'm asking
because I'm trying to figure out whether this console is or isn't part
of the problem.

> The debugger still stops after launching the initial threads,
> hiding the remaining console output, as shown below. I verified that the
> problem exists with both ucrt64 and mingw64 runtimes.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from 
> c:/home/juanjo/src/tensor/build-msys2-ucrt64/tests/test_rand.exe...
> (gdb) run
> Starting program: 
> c:\home\juanjo\src\tensor\build-msys2-ucrt64\tests\test_rand.exe 
> [New Thread 9944.0x1a28]
> [New Thread 9944.0x28c0]
> [New Thread 9944.0x3a00]
> <--- Here it stops. If I press <enter> it shows the console output.

This seems to indicate that there's some incompatibility between the
way GDB outputs stuff to its stdout and the device/program which
displays that stuff.  I don't yet understand well enough what you are
doing differently from the "usual" use of GDB on MS-Windows (which
works just fine), so I cannot tell anything more intelligent.  UCRT
may or may not be a part of the problem, but I don't have any
experience with using Windows programs linked against UCRT instead of
MSVCRT.