Re: various gdba bugs and requests

[Nick Roberts]

 > I finally started using gdba with gdb-many-windows set to 't'.  Nice
 > stuff!  If I maximize the frame and enable the toolbar, it is as nice
 > as any GUI debugger I've used.
 > 
 > I have run across a few minor problems though.

Thanks for a comprehensive review.  I am aware of most of these problems - I'm
just not sure what to do about them so my replies mght be a bit disappointing.

 > I'm using x86 Fedora Core 6 plus the system gdb, which says:
 > 
 >     opsy. gdb --version
 >     GNU gdb Red Hat Linux (6.5-15.fc6rh)
 > 
 > 1. I made a new frame for gdba and maximized it.  Then I moved it to
 > another virtual desktop.  gdb ran for a long time so I switched back
 > to my primary desktop and worked on other things.  When gdb finally
 > hit a breakpoint, the gud buffer appeared on one of my existing
 > frames.

I'm not sure if is a virtual desktop or a frame problem.  I don't know
why the gud buffer appeared.  GUD should just pop up a source buffer,
generally in the window where the source was previously or the frame of
the GUD buffer.

 > In this situation I'd prefer that this not happen -- I want gud to
 > remain confined to the frame on the other desktop.  Perhaps there
 > could be a variable of some kind to control the pop-up behavior, plus
 > maybe a hook that is run when gdb changes state (I didn't look to see
 > if there is one yet, so I'm sorry if this already happens).

To really understand what is happening you need to send a way to reproduce it.

 > 2. If I type too quickly I often see "Unexpected `starting' annotation".
 > This happens most often when I type "n" and then hit enter a number of
 > times to next through a function.

This is because GDB is still running and Emacs doesn't know if the input is for
GDB (in which case it should be queued) or for the program being debugged (in
which case it should be sent straight away). If your program doesn't use IO you
can apply the patch below.  Note that Emacs should still recover after this
error.

 > 3. At one point I restarted the inferior process using "run".  gud
 > seemed to lose track of the inferior completely -- the stack window no
 > longer showed the stack; the breakpoints and locals windows did not
 > update.
 > 
 > Exiting gud and restarting the debug session fixed this.  But, that is
 > pretty drastic.

This shouldn't happen.  Please send a testcase.

 > 4. I'd like a way to arrange the windows differently.  The standard
 > setup isn't to my taste.

Eclipse is superior in this respect.  I sometimes use gdb-many-windows but
generally I just pop up extra buffers in their own frames as I need them, from
the menu-bar.

 > 5. I found the green stop-sign icon somewhat confusing.

There are two buttons that share one location on the tool bar: a red one with
the word "STOP" that is visible when the inferior is running and stops
execution (usually sends a SIGINT) ; and a green one with the word "GO" that is
visible when execution has stopped and invokes "run" if the program has not
started or has exited, or "continue" if execution has stopped in the inferior.
This means if you want to restart execution in the middle of a session then you
need to enter "run" in the GUD buffer.  This is slightly inconvenient but I
don't think it's as bad as having three separate buttons for "run", "continue"
and interrupt (Ctrl-C on the command line).  To see what this is like try
"gdb --fullname" from the minibuffer.

 > 6. I often find that gdb acts strangely or sometimes crashes; one
 > thing that is nice about the Emacs approach to a gdb UI is that a lot
 > of state is kept in the gud buffer, so I can kill gdb, restart, search
 > backward and not lose too much.  Still, it would be nice if gud
 > offered a way to save the state of a debug session -- say, the cwd,
 > the command line, and the breakpoints (plus their conditions,
 > commands, etc).

If GDB crashes then that's a bug which should be reported to the GDB mailing
list.  Emacs could keep session information but how would this be more
convenient than using the GDB command "set logging on"?

 > 7. Right now if I set a breakpoint (using C-x SPC), then edit text
 > earlier in that file, recompile, and re-run the inferior, the
 > breakpoint will be in the "wrong" location.  This happens because the
 > breakpoint is set by file/line.
 >
 > It would be cool if gud put a marker on a breakpoint's location and
 > then used the marker location to move the breakpoint.  Perhaps this
 > could be done by moving it when gdb notices that the inferior
 > executable has changed.

Yes, I think Visual Studio DTRT but presumably it is just one program.  It's
difficult for Emacs to communicate such a change to GDB.

 > 8. I notice strange frame-raising behavior sometimes.  If I set a
 > command on a breakpoint that ends with "cont" and then the inferior
 > runs for a long time, the emacs frame showing the gud buffer will
 > constantly raise itself.  Also the gdb status on the mode line will
 > flicker rapidly between running and stopped.

Emacs processes all output from GDB and the flicker is present because
execution is repeatedly stopping and starting.  Maybe I could stop the
gud buffer constantly raising itself but I don't see that.  Do you see
it if you start with "emacs -Q"?

 > In GNU Emacs 22.0.990.1 (i386-koji-linux-gnu, GTK+ Version 2.10.11)

I believe Fedora 7 has a backport for Emacs 22.1.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


*** gdb-ui.el   13 Sep 2007 18:01:14 +1200      1.206.2.5
--- gdb-ui.el   15 Sep 2007 20:09:26 +1200      
*************** The key should be one of the cars in `gd
*** 1132,1151 ****
    "A comint send filter for gdb.
  This filter may simply queue input for a later time."
    (when gdb-ready
!       (with-current-buffer gud-comint-buffer
!       (let ((inhibit-read-only t))
!         (remove-text-properties (point-min) (point-max) '(face))))
!       (if gud-running
!         (progn
!           (let ((item (concat string "\n")))
!             (if gdb-enable-debug (push (cons 'send item) gdb-debug-log))
!             (process-send-string proc item)))
!       (if (string-match "\\\\\\'" string)
!           (setq gdb-continuation (concat gdb-continuation string "\n"))
!         (let ((item (concat gdb-continuation string
!                             (if (not comint-input-sender-no-newline) "\n"))))
!           (gdb-enqueue-input item)
!           (setq gdb-continuation nil))))))
  
  ;; Note: Stuff enqueued here will be sent to the next prompt, even if it
  ;; is a query, or other non-top-level prompt.
--- 1132,1146 ----
    "A comint send filter for gdb.
  This filter may simply queue input for a later time."
    (when gdb-ready
!     (with-current-buffer gud-comint-buffer
!       (let ((inhibit-read-only t))
!       (remove-text-properties (point-min) (point-max) '(face))))
!     (if (string-match "\\\\\\'" string)
!       (setq gdb-continuation (concat gdb-continuation string "\n"))
!       (let ((item (concat gdb-continuation string
!                         (if (not comint-input-sender-no-newline) "\n"))))
!       (gdb-enqueue-input item)
!       (setq gdb-continuation nil)))))
  
  ;; Note: Stuff enqueued here will be sent to the next prompt, even if it
  ;; is a query, or other non-top-level prompt.