Eli Zaretskii <eliz@gnu.org> writes:
>> From: Juan José García-Ripoll
>> It therefore seems that whatever issues are hiding in Emacs' support for
>> GDB's new facilities for programming ("-i=mi" command line option and
>> corresponding code in GUD).
>
> Yes, I suspected that.

I think I have identified the problem. The code in Emacs assumes that
all process output is going to be prefixed by @. This is only the case
for truely asynchronous debugging (see
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Stream-Records.html#GDB_002fMI-Stream-Records).

There seems to be code in gdb-mi.el for transforming the debugging
experience into a remote one, such as gdb-inferior-io--init-proc, which
aims to redirect the subprocess to a tty, but this seems to have no
effect on Windows.

Indeed, if once sets a tracepoint around gud-filter and
gud-gdbmi-marker-filter, the output is very different on Linux and on
Windows (see text files attached). Linux has successfully redirected the
output of the debugged subprocess, while the MSYS2 process gets the
output of the process mixed with GDB output.

I am a bit stuck. I assume I should simply use the old gud-gdb interface.

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