bug#3650: M-x gdb unusable on Windows

[Kenichi Handa]

In article <4A3F8EAC.5010009@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

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

It seems that this problem is not specific to Windows.  On
GNU/Linux, to debug a program compiled using libtool, I have
to to debug ./.libs/PROGNAME.  In that case, even if the
current directory has .gdbinit, it is not loaded in the gdb
session because gdb starts with the directory ./.libs.

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

This doesn't happen to me.  I don't know why.  I built emacs
by manually deleting "-o2" from src/makefile after running
nt/configure.bat.  Does it change the situation?!?

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

In my M-x gdb session, that buffer is not created!?!

>     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

Menu->Gud->GDB-UI->Separate IO doesn't cause that error.
Actually gdb-use-separate-io-buffer is a variable defined in
gdb-mi.el.

> Problem 4 is that enabling GUD tooltips results messages like the following:

>     error in process filter: Args out of range: "", 0, -1 [2 times]


M-x gud-tooltip-mode RET doesn't cause that problem.

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

It seems that my environment is different from yours.

---
Kenichi Handa
handa@m17n.org