bug#3650: M-x gdb unusable on Windows

Jason Rumney <[email protected]>
Newsgroups gmane.emacs.bugs,gmane.emacs.pretest.bugs
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.