bug#3650: M-x gdb unusable on Windows

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 02 Nov 2019 07:04:39 +0100
> Cc: 3650@debbugs.gnu.org
> 
> Jason Rumney <jasonr@gnu.org> writes:
> 
> > I just tried it, and it seems to be even worse than I remembered.
> >
> > Problem 1 is that the default directory of gdb is the directory where the Emacs
> > executable is even though I started it from the source directory and specified
> > oo/i386/emacs.exe as the executable to debug. This means that .gdbinit needs to
> > be "source"d in manually. In addition, gud is unable to find source files that
> > are not already being visited:
> >
> >    (gdb) break fontset_find_font
> >    Breakpoint 1 at 0x10f9dd7: file fontset.c, line 527.
> >    (gdb) list :1
> >    No source file named  in loaded symbols.
> >
> >
> > Problem 2 is that Emacs output (including the results of pp and pr) is
> > redirected to a buffer entitled *input/output of emacs.exe*, or at least 
> > that is what the intention appears to be.  That buffer is populated as follows
> > when gdb starts, and never updates:
> >
> >    c:\GnuWin32\bin\sleep.exe: cannot read realtime clock: Invalid argument
> >       Process gdb-inferior exited abnormally with code 1
> >
> > Problem 3 is that there appears to be a menu toggle for disabling this output
> > redirection, but it does not function. Instead, I see this in *Messages*:
> >
> >    Symbol's function definition is void: gdb-use-separate-io-buffer
> >
> >
> > Problem 4 is that enabling GUD tooltips results messages like the following:
> >
> >    error in process filter: Args out of range: "", 0, -1 [2 times]
> >
> >
> > Problem 5 is the general slowness. This one is probably down to Windows poor
> > subprocess and pipe support, but the rest seem to be real problems within
> > gud/gdb-mi.
> 
> This was reported 10 years ago.
> 
> Is this still an issue on modern versions of Emacs?

Most of the problems are gone, not in the least because we use
gdb-mi.el nowadays.  But some are still there, although I don't see
what we can do about that:

  . the initial directory is still where the binary lives, but that is
    not Windows specific: Emacs behaves like that on Posix platforms
    as well

  . pp and other similar commands in .gdbinit don't work, but that's
    AFAIU because gdb-mi cannot separate the GDB output from the
    program's output on MS-Windows

All the other problems are gone, and the corresponding features work
as expected.