This bug should be assigned to the xemacs package, but I could not find the component in the bugzilla components list. These are the relevant packages: xemacs-21.1.12-3, emacs-20.7-17, gdb-5.0-7. XEmacs does not interact with gdb correctly in its debugging mode. When I enter debugging mode (M-x gdb), it launches gdb in its buffer as expected. But no command works. When I type a simple command like list at its (gdb) prompt, nothing happens. On the other hand, emacs works fine.
it works just fine here, with simple test programs... can you be more specific?
I just tried with a simple test case: #include <stdio.h> int main(void) { printf("Hello, sunshine\n"); printf("Goodbye, rain\n"); return 0; } This was compiled with gcc -g -o foo and invoked with M-x gdb, "gdb foo". This is what the gdb buffer looks like: Current directory is /tmp/ GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) list But nothing appears after "list". It sort of hangs until I type C-c C-c, upon which it writes "Quit" and displays the (gdb) prompt again. There is no other meaningful output that I can see. Gdb works fine standalone or with Emacs. It only has trouble with xemacs. ps shows the command line as "/usr/bin/gdb --annotate=2 /tmp/foo".
The problem seems related to jde. Here's how to reproduce: 1. Start xemacs. 2. Load jde. You can simply start editing "foo.java". It does not have to have content. 3. Do M-x gdb on a C executable.
As you say, it seems to be related to jde usage. It works just fine when not using JDE (which then is the obvious workaround).
OK, I got no response on the jde mailing list and this would touch a lot JDE - they're assuming that all debugging will be java debugging. Can't fix that without major brainsurgery on code. Workaround: Run standard debugging and java editing in different XEmacs sessions.