On 04/05/2012 1:39 PM, Ken Brown wrote:
On 5/3/2012 4:10 PM, Ryan Johnson wrote:
On 03/05/2012 10:45 AM, Ken Brown wrote:
On 5/2/2012 5:02 PM, Ryan Johnson wrote:
On 02/05/2012 1:16 PM, Ryan Johnson wrote:
The gdb-mi integration also seems to work reasonably well, with a few
exceptions:
[...]
(This was fixed once and was a Cygwin bug, so I think it won't be hard
for me to resurrect my test case and get it fixed again.)
This is now fixed (http://cygwin.com/ml/cygwin/2012-05/msg00084.html).
Ack.
One last note: I normally use emacs in terminal mode, but couldn't do
that inside gdb (for obvious reasons). Some of the behaviors I
observed
before -- including seg faults -- may be terminal-specific, and
some of
the new strangeness I'm pointing out now may be X11-specific... or it
might just be the difference between -O0 and -O2.
What do you mean by "terminal mode"? Do you mean you run emacs under
mintty? Or do you run it under xterm with the -nw switch? And could
you elaborate on the "obvious reasons"? I don't see why you can't run
emacs in a terminal under gdb; or attach to it from a different
terminal if that's more convenient.
I usually run under mintty with -nw. When following the instructions in
that /etc/DEBUG file you pointed me at, the .gdbinit included
breakpoints and other pre-main intializations to perform that would not
happen if I merely attached to a running emacs. However, that will
probably be my next attempt, since the X11 route didn't pan out (and I
dislike using the graphical version).
I'm not sure why you're using the -nw switch when you start emacs in
mintty. As far as I can tell from the documentation, -nw shouldn't do
anything if you're not running under X.
I have DISPLAY defined for things like gnuplot, but don't want emacs to
use it even when X is available...
I still don't see why you can't run emacs under gdb in mintty:
$ cd emacs-24.0.95/src/
$ gdb ./emacs.exe
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/emacs-24.0.95/src/emacs.exe...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not
from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm
Breakpoint 1 at 0x4ded26: file emacs.c, line 394.
Temporary breakpoint 2 at 0x4f8970: file sysdep.c, line 855.
(gdb) r -Q
[...]
Now if it crashes, won't you be returned to gdb where you can get a
backtrace?
I guess that might work, since I wouldn't do anything but grab the
backtrace. It just doesn't work well to mix gdb and curses-using apps in
the same terminal.
And attaching from another mintty also works; gdb processes the
.gdbinit file just fine as long as you start gdb from the emacs src
directory:
Duh... I hadn't thought to specify the --pid switch; I usually just
attach inside gdb, and that's too late for the purposes of .gdbinit.
Thanks!
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
