[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#3650: M-x gdb unusable on Windows
From: |
Dan Nicolaescu |
Subject: |
bug#3650: M-x gdb unusable on Windows |
Date: |
Mon, 22 Jun 2009 20:37:26 -0700 (PDT) |
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.
- bug#3208: 23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32), Jason Rumney, 2009/06/18
- bug#3208: 23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32), Jason Rumney, 2009/06/22
- bug#3208: 23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32), Kenichi Handa, 2009/06/22
- bug#3208: 23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32), Jason Rumney, 2009/06/22
- bug#3208: 23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32), Kenichi Handa, 2009/06/22
- bug#3208: 23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32), Jason Rumney, 2009/06/22
- bug#3650: M-x gdb unusable on Windows, Jason Rumney, 2009/06/22
- bug#3650: M-x gdb unusable on Windows, Kenichi Handa, 2009/06/22
- bug#3650: M-x gdb unusable on Windows,
Dan Nicolaescu <=
- bug#3650: M-x gdb unusable on Windows, Nick Roberts, 2009/06/23
- bug#3650: M-x gdb unusable on Windows, Kenichi Handa, 2009/06/23
- bug#3650: M-x gdb unusable on Windows, Nick Roberts, 2009/06/23
- bug#3650: M-x gdb unusable on Windows, Jason Rumney, 2009/06/23
- bug#3650: M-x gdb unusable on Windows, Kenichi Handa, 2009/06/23
- bug#3650: M-x gdb unusable on Windows, Dan Nicolaescu, 2009/06/23
- bug#3650: M-x gdb unusable on Windows, Kenichi Handa, 2009/06/25
- bug#3650: M-x gdb unusable on Windows, Nick Roberts, 2009/06/25
- bug#3650: M-x gdb unusable on Windows, Kenichi Handa, 2009/06/25
- bug#3208: 23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32), Kenichi Handa, 2009/06/24