bug#3650: M-x gdb unusable on Windows

[Dan Nicolaescu]

Kenichi Handa <handa@m17n.org> writes:

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

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.