bug#3650: M-x gdb unusable on Windows

[Stefan Kangas <stefan@marxist.se>]

Jason Rumney <jasonr@gnu.org> writes:

> Jason Rumney wrote:
>> Kenichi Handa wrote:
>>
>>> By the way, I also installed gdb-6.8-mingw-3.tar.bz2.  But,
>>> with "M-x gdb", pp and pr commands doesn't work.  They print
>>> nothing.  They do work when gdb is invoked from command
>>> line.  Do you know what is wrong?
>>>   
>>
>> I've often had problems in the past using debuggers under Emacs on Windows
>> (under Emacs 21 and early 22 development versions though, so I haven't tried
>> the new gdb-ui extensively), so I always use the command line.
>
> 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?

Best regards,
Stefan Kangas