bug#3650: M-x gdb unusable on Windows

[Kenichi Handa <handa@m17n.org>]

In article <19008.29888.625193.823405@totara.tehura.co.nz>, nickrob@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@m17n.org