emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gdb fails to flush output (msys2)


From: Eli Zaretskii
Subject: Re: gdb fails to flush output (msys2)
Date: Tue, 15 Mar 2022 18:53:09 +0200

> From: Juan José García-Ripoll
>  <juanjose.garciaripoll@gmail.com>
> Date: Tue, 15 Mar 2022 16:12:57 +0100
> 
> 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.

This GDB feature doesn't work on MS-Windows, only on Posix systems.
But my problem is to understand how come my own debugging using
gdb-mi.el on MS-Windows generally works regardless of this issue with
separating the I/O of the debuggee.  I'm being slowly drawn to the
conclusion that the solution of that puzzle is in what your program
that you are debugging does.  E.g., do you see something similar if
you debug any other console MinGW program with "M-x gdb"?

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

That's a possibility, yes.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]