GNU bug report logs - #3650
M-x gdb unusable on Windows

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 3650 <at> debbugs.gnu.org, jasonr <at> gnu.org
Subject: bug#3650: M-x gdb unusable on Windows
Date: Sat, 02 Nov 2019 10:41:05 +0200

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sat, 02 Nov 2019 07:04:39 +0100
> Cc: 3650 <at> debbugs.gnu.org
> 
> Jason Rumney <jasonr <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.