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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3650 in the body.
You can then email your comments to 3650 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: emacs-pretest-bug <emacs-pretest-bug <at> gnu.org>
Subject: M-x gdb unusable on Windows
Date: Mon, 22 Jun 2009 22:01:16 +0800

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.

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Jason Rumney <jasonr <at> gnu.org>, 3650 <at> debbugs.gnu.org
Cc: emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Tue, 23 Jun 2009 10:59:29 +0900

In article <4A3F8EAC.5010009 <at> gnu.org>, Jason Rumney <jasonr <at> 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 <at> m17n.org

Message #18 received at 3650 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 3650 <at> debbugs.gnu.org, Jason Rumney <jasonr <at> gnu.org>
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Mon, 22 Jun 2009 20:37:26 -0700 (PDT)

Kenichi Handa <handa <at> m17n.org> writes:

  > In article <4A3F8EAC.5010009 <at> gnu.org>, Jason Rumney <jasonr <at> 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.

This is extremely annoying, I've had to add 
(setq gud-chdir-before-run nil) 
to my .emacs at some point to get around this.

The current default completely breaks if you want to debug things that
use relative file names.  Say if you have:

subdir1/binary -blah subdir2/foo -bar subdir3/baz

That you can debug from the command like simply doing:

gdb --args subdir1/binary -blah subdir2/foo -bar subdir3/baz

you can't debug this by default by doing:

M-x gdb RET --args subdir1/binary -blah subdir2/foo -bar subdir3/baz

like one could do with emacs-21... 

Things work much better if you  set 
   (setq gud-chdir-before-run nil)

Not sure what's the point of this change, making M-x gdb different from
doing the same thing from the command line by default does not sound
like a great idea.

Message #23 received at 3650 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: nickrob <at> snap.net.nz (Nick Roberts)
To: Jason Rumney <jasonr <at> gnu.org>, 3650 <at> debbugs.gnu.org
Cc: emacs-pretest-bug <emacs-pretest-bug <at> gnu.org>
Subject: bug#3650: M-x gdb unusable on Windows
Date: Tue, 23 Jun 2009 18:09:39 +1200

Jason Rumney 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?

Are you sure they print nothing or is it just that the output isn't
being flushed?  The commentary in gdb-ui.el has some advice about using
Emacs and GDB on Windows:

  ;; If you are using Emacs and GDB on Windows you will need to flush the buffer
  ;; explicitly in your program if you want timely display of I/O in Emacs.
  ;; Alternatively you can make the output stream unbuffered, for example, by
  ;; using a macro:

  ;;           #ifdef UNBUFFERED
  ;;	     setvbuf (stdout, (char *) NULL, _IONBF, 0);
  ;;	     #endif

  ;; and compiling with -DUNBUFFERED while debugging.

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

Perhaps you mean:

  I just tried it, and I can't get it to work.

Asking on this list if others are successfully using it will probably answer
the question as to whether the problem is at your end or not.  Saying it
is unusable is a bit cheap.

 > Problem 1 is that ...

What version of Emacs are you using?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Message #28 received at 3650 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: nickrob <at> snap.net.nz (Nick Roberts)
To: Kenichi Handa <handa <at> m17n.org>, 3650 <at> debbugs.gnu.org
Cc: Jason Rumney <jasonr <at> gnu.org>, emacs-pretest-bug <at> gnu.org
Subject: bug#3650: M-x gdb unusable on Windows
Date: Tue, 23 Jun 2009 18:22:56 +1200

Kenichi Handa writes:
 > In article <4A3F8EAC.5010009 <at> gnu.org>, Jason Rumney <jasonr <at> 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.

You can change the behaviour to keep the current directory by setting
gud-chdir-before-run to nil.  The problem with this arrangement is that it
might not find your .gdbinit file (as with Emacs) and it's generally less
obvious what the default directory is in Emacs than what the current
working directory is from the command line.

Dan might find it "extremely annoying" but this change goes back to
2001-05-24 when gud.el was in the lisp directory.

I quite like this default and suggest keeping it, but it might be a good
idea to document the variable gud-chdir-before-run in the manual.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Message #43 received at 3650 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: nickrob <at> snap.net.nz (Nick Roberts)
Cc: 3650 <at> debbugs.gnu.org, jasonr <at> gnu.org
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Tue, 23 Jun 2009 16:38:30 +0900

In article <19008.29888.625193.823405 <at> totara.tehura.co.nz>, nickrob <at> snap.net.nz (Nick Roberts) writes:

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

> You can change the behaviour to keep the current directory by setting
> gud-chdir-before-run to nil.  The problem with this arrangement is that it
> might not find your .gdbinit file (as with Emacs) and it's generally less
> obvious what the default directory is in Emacs than what the current
> working directory is from the command line.

How about making gud don't change directory when a program
is specified with a relative path if gud-chdir-before-run is
not nil nor t (I can't think of a good symbol at the
moment)?  I usually specify a relative path at M-x gdb when
I'm in a buffer visiting a source file of a program to
debug.  If I'm in a buffer not related to a program to
debug, I usually specify the program by an absolute path.

> but it might be a good idea to document the variable
> gud-chdir-before-run in the manual.

Sure.

---
Kenichi Handa
handa <at> m17n.org

Message #48 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Nick Roberts <nickrob <at> snap.net.nz>
Cc: 3650 <at> debbugs.gnu.org,
        emacs-pretest-bug <emacs-pretest-bug <at> gnu.org>
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Tue, 23 Jun 2009 15:59:27 +0800

Nick Roberts wrote:
> What version of Emacs are you using?
>   

Both trunk and EMACS_23_1_RC. The trunk is slightly better, as the 
branch additionally stops responding after some time debugging (around 
the same time that tooltips stop working - which happened before I 
turned on tooltips the first time I tested on trunk so I mistakenly 
thought they didn't work at all).

Message #58 received at 3650 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Nick Roberts <nickrob <at> snap.net.nz>, 3650 <at> debbugs.gnu.org
Cc: jasonr <at> gnu.org
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Tue, 23 Jun 2009 22:22:05 +0900

In article <19008.29091.473126.629092 <at> totara.tehura.co.nz>, nickrob <at> snap.net.nz (Nick Roberts) writes:

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

> Are you sure they print nothing or is it just that the output isn't
> being flushed?  The commentary in gdb-ui.el has some advice about using
> Emacs and GDB on Windows:

>   ;; If you are using Emacs and GDB on Windows you will need to flush the buffer
>   ;; explicitly in your program if you want timely display of I/O in Emacs.
>   ;; Alternatively you can make the output stream unbuffered, for example, by
>   ;; using a macro:

>   ;;           #ifdef UNBUFFERED
>   ;;	     setvbuf (stdout, (char *) NULL, _IONBF, 0);
>   ;;	     #endif

>   ;; and compiling with -DUNBUFFERED while debugging.

Thank you for the info.  When I added "fflush (stderr);" at
the end of the function debug_print, pp and pr commands
started to work on Windows (mingw).

But, still C-c C-n in *gud* buffer, C-x C-a C-b in a source
file buffer don't work.

When I type C-c C-n in *gud* buffer,
  "error in process filter: Unexpected `starting' annocation"
is shown in the echo area, and no command is accepted here
after.

When I type C-x C-a C-b in a source file buffer, the gdb
prompt in *gud* buffer is erased, and any further commands
in *gud* just show the same output as "br info", and the
menu bar keep flushing.

---
Kenichi Handa
handa <at> m17n.org

Message #61 received at 3650 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 3650 <at> debbugs.gnu.org, Nick Roberts <nickrob <at> snap.net.nz>
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Tue, 23 Jun 2009 10:08:07 -0700 (PDT)

Kenichi Handa <handa <at> m17n.org> writes:

  > In article <19008.29091.473126.629092 <at> totara.tehura.co.nz>, nickrob <at> snap.net.nz (Nick Roberts) writes:
  > 
  > > >> 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?
  > 
  > > Are you sure they print nothing or is it just that the output isn't
  > > being flushed?  The commentary in gdb-ui.el has some advice about using
  > > Emacs and GDB on Windows:
  > 
  > >   ;; If you are using Emacs and GDB on Windows you will need to flush the buffer
  > >   ;; explicitly in your program if you want timely display of I/O in Emacs.
  > >   ;; Alternatively you can make the output stream unbuffered, for example, by
  > >   ;; using a macro:
  > 
  > >   ;;           #ifdef UNBUFFERED
  > >   ;;	     setvbuf (stdout, (char *) NULL, _IONBF, 0);
  > >   ;;	     #endif
  > 
  > >   ;; and compiling with -DUNBUFFERED while debugging.
  > 
  > Thank you for the info.  When I added "fflush (stderr);" at
  > the end of the function debug_print, pp and pr commands
  > started to work on Windows (mingw).
  > 
  > But, still C-c C-n in *gud* buffer, C-x C-a C-b in a source
  > file buffer don't work.
  > 
  > When I type C-c C-n in *gud* buffer,
  >   "error in process filter: Unexpected `starting' annocation"
  > is shown in the echo area, and no command is accepted here
  > after.

I hit this regularly when running gdb against a simulator (i.e. slow
response from the target) and type
c RET c RET 
fast, so the second c comes before hitting the next breakpoint.  It
seems that gud gets confused in interpreting the response from gdb...

After that anything I type print the result of "info breakpoints".

  > When I type C-x C-a C-b in a source file buffer, the gdb
  > prompt in *gud* buffer is erased, and any further commands
  > in *gud* just show the same output as "br info", and the
  > menu bar keep flushing.

Sometimes typing
quit RET
and then answering "no" will clear things up and it's possible to
continue... but this is just a hack...

Message #66 received at 3650 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: 李宝亮 <happylibaoliang <at> gmail.com>
To: Dan Nicolaescu <dann <at> ics.uci.edu>, 3650 <at> debbugs.gnu.org
Cc: Kenichi Handa <handa <at> m17n.org>
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Wed, 24 Jun 2009 09:29:35 +0800

excuse me ,but how can i unsubscribe this mailing list?

2009/6/24, Dan Nicolaescu <dann <at> ics.uci.edu>:
> Kenichi Handa <handa <at> m17n.org> writes:
>
>   > In article <19008.29091.473126.629092 <at> totara.tehura.co.nz>,
> nickrob <at> snap.net.nz (Nick Roberts) writes:
>   >
>   > > >> 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?
>   >
>   > > Are you sure they print nothing or is it just that the output isn't
>   > > being flushed?  The commentary in gdb-ui.el has some advice about
> using
>   > > Emacs and GDB on Windows:
>   >
>   > >   ;; If you are using Emacs and GDB on Windows you will need to flush
> the buffer
>   > >   ;; explicitly in your program if you want timely display of I/O in
> Emacs.
>   > >   ;; Alternatively you can make the output stream unbuffered, for
> example, by
>   > >   ;; using a macro:
>   >
>   > >   ;;           #ifdef UNBUFFERED
>   > >   ;;	     setvbuf (stdout, (char *) NULL, _IONBF, 0);
>   > >   ;;	     #endif
>   >
>   > >   ;; and compiling with -DUNBUFFERED while debugging.
>   >
>   > Thank you for the info.  When I added "fflush (stderr);" at
>   > the end of the function debug_print, pp and pr commands
>   > started to work on Windows (mingw).
>   >
>   > But, still C-c C-n in *gud* buffer, C-x C-a C-b in a source
>   > file buffer don't work.
>   >
>   > When I type C-c C-n in *gud* buffer,
>   >   "error in process filter: Unexpected `starting' annocation"
>   > is shown in the echo area, and no command is accepted here
>   > after.
>
> I hit this regularly when running gdb against a simulator (i.e. slow
> response from the target) and type
> c RET c RET
> fast, so the second c comes before hitting the next breakpoint.  It
> seems that gud gets confused in interpreting the response from gdb...
>
> After that anything I type print the result of "info breakpoints".
>
>   > When I type C-x C-a C-b in a source file buffer, the gdb
>   > prompt in *gud* buffer is erased, and any further commands
>   > in *gud* just show the same output as "br info", and the
>   > menu bar keep flushing.
>
> Sometimes typing
> quit RET
> and then answering "no" will clear things up and it's possible to
> continue... but this is just a hack...
>
>
>
>
>
>

Message #71 received at 3650 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: 3650 <at> debbugs.gnu.org
Cc: nickrob <at> snap.net.nz
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Thu, 25 Jun 2009 14:50:52 +0900

In article <E1MJ5wr-0007eb-Qn <at> etlken>, Kenichi Handa <handa <at> m17n.org> writes:

> But, still C-c C-n in *gud* buffer, C-x C-a C-b in a source
> file buffer don't work.

I've just found that, with the latest code, they don't work
even on GNU/Linux, they show the same behaviour as on
Windows.  But, with the code of EMACS_23_1_RC, those
commands work on GNU/Linux.  I'm now building EMACS_23_1_RC
on Windows to check if they work.

---
Kenichi Handa
handa <at> m17n.org

Message #76 received at 3650 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: nickrob <at> snap.net.nz (Nick Roberts)
To: Kenichi Handa <handa <at> m17n.org>
Cc: 3650 <at> debbugs.gnu.org
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Thu, 25 Jun 2009 18:13:50 +1200

Kenichi Handa writes:
 > In article <E1MJ5wr-0007eb-Qn <at> etlken>, Kenichi Handa <handa <at> m17n.org> writes:
 > 
 > > But, still C-c C-n in *gud* buffer, C-x C-a C-b in a source
 > > file buffer don't work.
 > 
 > I've just found that, with the latest code, they don't work
 > even on GNU/Linux, they show the same behaviour as on
 > Windows.  But, with the code of EMACS_23_1_RC, those
 > commands work on GNU/Linux.  I'm now building EMACS_23_1_RC
 > on Windows to check if they work.

Some things won't work for a while on trunk as there are major changes
happening there now:

gdb-ui.el           ->      gdb-mi.el
Annotations         ->      GDB/MI
gdb - annotate=3    ->      gdb -i=mi

Some of this work is being done by Dmitry Dzhus as part of the Google Summer
of Code project "Emacs GDB/MI migration":

http://socghop.appspot.com/student_project/show/google/gsoc2009/karlberry/t124022551883

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Message #81 received at 3650 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: nickrob <at> snap.net.nz (Nick Roberts)
Cc: 3650 <at> debbugs.gnu.org
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Thu, 25 Jun 2009 16:51:22 +0900

In article <19011.5534.127890.563311 <at> totara.tehura.co.nz>, nickrob <at> snap.net.nz (Nick Roberts) writes:

> Kenichi Handa writes:
> In article <E1MJ5wr-0007eb-Qn <at> etlken>, Kenichi Handa <handa <at> m17n.org> writes:
> 
> > But, still C-c C-n in *gud* buffer, C-x C-a C-b in a source
> > file buffer don't work.
> 
> I've just found that, with the latest code, they don't work
> even on GNU/Linux, they show the same behaviour as on
> Windows.  But, with the code of EMACS_23_1_RC, those
> commands work on GNU/Linux.  I'm now building EMACS_23_1_RC
> on Windows to check if they work.

> Some things won't work for a while on trunk as there are major changes
> happening there now:

> gdb-ui.el           ->      gdb-mi.el
> Annotations         ->      GDB/MI
> gdb - annotate=3    ->      gdb -i=mi

Thank you for the info.  I found that when I use gud in
EMACS_23_1_RC, those commands work on Windows, but pp and pr
commands doesn't work even if what I'm debugging is emacs of
the trunk (thus debug_print of that emacs has fflush
(stderr)).  Strange.

So, I'm now debugging Emacs on Windows with emacs of the
trunk but using gud and gdb-ui of EMACS_23_1_RC.  It seems
that this combination works perfectly.

---
Kenichi Handa
handa <at> m17n.org

Message #86 received at 3650 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: 3650 <at> debbugs.gnu.org
Subject: Re: M-x gdb unusable on Windows
Date: Sat, 02 Nov 2019 07:04:39 +0100

Jason Rumney <jasonr <at> 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

Message #89 received at 3650 <at> debbugs.gnu.org (full text, mbox):

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

Message #92 received at 3650 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Kangas <stefan <at> marxist.se>, 3650 <at> debbugs.gnu.org, jasonr <at> gnu.org
Subject: Re: bug#3650: M-x gdb unusable on Windows
Date: Wed, 13 Apr 2022 02:40:14 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

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

Since the reported errors are gone, and the two remaining ones isn't
something we can do anything about, I'm therefore closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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