Re: gdb fails to flush output (msys2)

["Juan José García-Ripoll" <juanjose.garciaripoll@gmail.com>]

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.

>> 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 program are you debugging?  Is it a native MS-Windows
> (a.k.a. "MinGW") program, or is it an MSYS2 program that depends on
> the MSYS DLL?  Also, is it a console program or something else, like a
> program using curses or some other unusual methods of writing to the
> screen?

I am debugging applications built using cmake + g++ natively (MinGW with
either ucrt64 or older runtimes). They are all console
applications. Launching the debugger from a terminal works for the same
application, but, of course, I lose integration with Emacs.

> 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)

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. 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.

-- 
Juan José García Ripoll
http://juanjose.garciaripoll.com
http://quinfog.hbar.es