Toolbar problems with GDB mode.

Toolbar problems with GDB mode.

[Jan D.]

Hello.

If a break point is reached in a C file, the file is displayed and the toolbar 
changes to the GDB toolbar.  When quitting gdb, the toolbar does not change 
back.  Not even if gdb-quit is run.

I started GDB with M-x gdb.

If I use M-x gdba it restores the menu bar OK, but gdba has so many other 
problems, so I can't use it.

I think (kill-local-variable 'tool-bar-map) should be run even if
(eq gud-minor-mode 'gdba) is false in this function (gdb-ui.el):

(defun gdb-quit ()
   "Kill the GUD interaction and gdb buffers and reset variables.
Use this command to exit a debugging session cleanly and reset
things like the toolbar and margin in the source buffers."
   (interactive)
   (dolist (buffer (buffer-list))
     (save-excursion
       (set-buffer buffer)
       (if (eq gud-minor-mode 'gdba)
           (if (string-match "^\*" (buffer-name))
               (kill-buffer nil)
             (if (display-graphic-p)
                 (remove-images (point-min) (point-max))
               (remove-strings (point-min) (point-max)))
             (setq left-margin-width 0)
             (setq gud-minor-mode nil)
             (kill-local-variable 'tool-bar-map)
             (setq gud-running nil)
             (if (get-buffer-window (current-buffer))
                 (set-window-margins (get-buffer-window
                                      (current-buffer))
                                     left-margin-width
                                     right-margin-width))))))
   (if (eq (selected-window) (minibuffer-window))
       (other-window 1))
   (delete-other-windows))


	Jan D.

Toolbar problems with GDB mode.

[Nick Roberts]

Jan D. writes:

 > Hello.
 > 
 > If a break point is reached in a C file, the file is displayed and the toolbar 
 > changes to the GDB toolbar.  When quitting gdb, the toolbar does not change 
 > back.  Not even if gdb-quit is run.
 > 
 > I started GDB with M-x gdb.
 > 
 > If I use M-x gdba it restores the menu bar OK, but gdba has so many other 
 > problems, so I can't use it.
 > 

Hmm. I'm very aware that gdba doesn't auto-display complex data structures
(arrays of structures or structures with arrays in) and plan to solve that
when I can find the stamina. If you are more specific about other problems
then I will try to solve them.

 > I think (kill-local-variable 'tool-bar-map) should be run even if
 > (eq gud-minor-mode 'gdba) is false in this function (gdb-ui.el):

That will restore the toolbar but it will also kill any buffer whose name
starts with `*'. I could replace:

        (if (eq gud-minor-mode 'gdba)
with    (if (memq gud-minor-mode '(gdb gdba))

which would do what you want. However, I wrote gdb-quit for gdba and
I've not analysed what other consequences that might have.

In my opinion, M-x gdb is quite limited. I'm guessing, but I bet most
people on this list use gdb from the command line when they debug emacs.
It has quite some nifty features that make it easier to use: completion
of GDB command names, completion of user-defined procedure names, <RET>
sometimes repeats the previous command (handy for stepping through the
program or looking at a listing), readline interface etc, etc...

Nick

Re: Toolbar problems with GDB mode.

[Jan D.]

> 
> Hmm. I'm very aware that gdba doesn't auto-display complex data structures
> (arrays of structures or structures with arrays in) and plan to solve that
> when I can find the stamina. If you are more specific about other problems
> then I will try to solve them.

I see that the GUD menu also hangs around after quitting gdb.

Well, I don't know if they are gdb (the program) problems or gdba (the mode)
problems.  I just upgraded gdb to 5.2.1.

For example, I do:
M-x gdba
Run gdba (like this): gdb -annotate=2 emacs

(The -annotate=2 is put there by gdba).
Then the .gdbinit puts two breakpoints, nr 2 in emacs.c and gdba loads
that file.  This is kind of annoying since I had the file I wanted to
debug visible, but now it is buried.  But this is not the big bug.

If I go to a C file and do C-x C-v C-a (set breakpoint), here is what
the *gud-emacs* buffer prints:

breakpoint     keep y   0x0810585c in abort at emacs.c:412
2   breakpoint     keep y   0x080db76f ---Type <return> to continue, or q <return> to quit---
in x_error_quitter at xterm.c:12727

I typed return at "quit---"

No break point is set.  This "--- Type <return> ..." pops up at a lot
of places, for example when running the program:
(gdb) r
Starting program: /home/jhd/src/emacs-gtk/src/emacs -geometry 80x40+0+0

Breakpoint 4, main (argc=3, argv
---Type <return> to continue, or q <return> to quit---
\x1a\x1aarg-name-end
=0xbffff434) at emacs.c:781
(gdb) 



> 
>  > I think (kill-local-variable 'tool-bar-map) should be run even if
>  > (eq gud-minor-mode 'gdba) is false in this function (gdb-ui.el):
> 
> That will restore the toolbar but it will also kill any buffer whose name
> starts with `*'. I could replace:

How can (kill-local-variable 'tool-bar-map) kill buffers?

>         (if (eq gud-minor-mode 'gdba)
> with    (if (memq gud-minor-mode '(gdb gdba))
> 
> which would do what you want. However, I wrote gdb-quit for gdba and
> I've not analysed what other consequences that might have.

Is gdb-quit supposed to be run manually?  It is not run if I type q
at the (gdb) prompt.

> In my opinion, M-x gdb is quite limited. I'm guessing, but I bet most
> people on this list use gdb from the command line when they debug emacs.
> It has quite some nifty features that make it easier to use: completion
> of GDB command names, completion of user-defined procedure names, <RET>
> sometimes repeats the previous command (handy for stepping through the
> program or looking at a listing), readline interface etc, etc...

When you wan't to see the source in a context, it is better that the
command line.

	Jan D.

Re: Toolbar problems with GDB mode.

[Nick Roberts]

 > I see that the GUD menu also hangs around after quitting gdb.

This could go too if gdb-quit is modified appropriately (and moved into
gud.el)

 > Well, I don't know if they are gdb (the program) problems or gdba (the mode)
 > problems.  I just upgraded gdb to 5.2.1.

The chances are about 99.9% that its with gdba.

 > For example, I do:
 > M-x gdba
 > Run gdba (like this): gdb -annotate=2 emacs
 > 
 > (The -annotate=2 is put there by gdba).
 > Then the .gdbinit puts two breakpoints, nr 2 in emacs.c and gdba loads
 > that file.  This is kind of annoying since I had the file I wanted to
 > debug visible, but now it is buried.  But this is not the big bug.
 
It doesn't load emacs.c because it has a breakpoint there but because
thats where the execution starts. Thats standard practice for GUI debuggers.

 > If I go to a C file and do C-x C-v C-a (set breakpoint), here is what
 > the *gud-emacs* buffer prints:
 > 
 > breakpoint     keep y   0x0810585c in abort at emacs.c:412
 > 2   breakpoint     keep y   0x080db76f ---Type <return> to continue, or q <return> to quit---
 > in x_error_quitter at xterm.c:12727
 > 
 > I typed return at "quit---"
 > 
 > No break point is set.  This "--- Type <return> ..." pops up at a lot
 > of places, for example when running the program:
 ...

gdba requires that the screen size for GDB is unlimited. In emacs, TERM = dumb
means that this is normally the case. I'm guessing you've got something in a
.gdbinit file (possibly in your home directory) that says (something like):

set height 24

You can recover from this by typing `set height 0' in the GUD buffer but its
tidier if its not set initially. `show height' should then give:

Number of lines gdb thinks are in a page is unlimited.

and gdba should work properly.

 > Is gdb-quit supposed to be run manually?  It is not run if I type q
 > at the (gdb) prompt.

Yes. Its a command in emacs. The problem is communication GDB and emacs. Quite
often emacs doesn't know what GDB is doing and thats what the annotations
used in gdba are for. With quit the status of the sub-process (GDB) changes
so perhaps I can hook gdb-quit up to that. I'll give it some thought.

Nick

Re: Toolbar problems with GDB mode.

[Jan D.]

>  > Then the .gdbinit puts two breakpoints, nr 2 in emacs.c and gdba loads
>  > that file.  This is kind of annoying since I had the file I wanted to
>  > debug visible, but now it is buried.  But this is not the big bug.
>  
> It doesn't load emacs.c because it has a breakpoint there but because
> thats where the execution starts. Thats standard practice for GUI debuggers.

Okay, but it is also the one thing i dislike with DDD for example.
In embedded development, one does not even have a main.  DDD then
loads a random file, which is annoying as it takes time.

I frequently do like this:
Go to line in file where I would like to break
C-x 2
start gdb in the upper window.
C-x 0 C-x C-v C-a

The last line is like one gesture, and gdba breaks that for me.  I
don't think it is a good idea to switch and hide file buffer a user
is looking at.  Isn't that the reason why for example compile
splits the frame in two windows, to keep the file the user is editing
in sight?

> gdba requires that the screen size for GDB is unlimited. In emacs, TERM = dumb
> means that this is normally the case. I'm guessing you've got something in a
> .gdbinit file (possibly in your home directory) that says (something like):
> 
> set height 24

The GDB default is 24 lines, and I had no terminfo entry for dumb,
hence GDB uses 24.  Adding a terminfo solves that.  But if gdba
requires a specific height, can it not do that as the first command
to GDB by itself?  Just a thought.

Another thing you should look at is starting gdba, stopping GDB
and killing the buffer, then starting gdba again.  It does funny
things, like showing a buffer named *Displayed expressions of emacs*,
and this is in *Messages*:
error in process filter: gdb-info-breakpoints-handler: Selecting deleted buffer
error in process filter: Selecting deleted buffer

	Jan D.

Re: Toolbar problems with GDB mode.

[Nick Roberts]

 > Okay, but it is also the one thing i dislike with DDD for example.
 > In embedded development, one does not even have a main.  DDD then
 > loads a random file, which is annoying as it takes time.

Do you use emacs for embedded development ? If so, could you please tell me
what gdba does ?

 > I frequently do like this:
 > Go to line in file where I would like to break
 > C-x 2
 > start gdb in the upper window.
 > C-x 0 C-x C-v C-a
 >
 > The last line is like one gesture, and gdba breaks that for me.  

I guess you mean C-x 0 C-x C-a C-b, but I get what you're saying. I had not
thought about that approach.

 > I don't think it is a good idea to switch and hide file buffer a user
 > is looking at. 

Yes but sometimes, as they say, it best to start at the beginning.

 > Isn't that the reason why for example compile
 > splits the frame in two windows, to keep the file the user is editing
 > in sight?

And presumably it would be a good idea for M-x gdb to do this also. Then
you wouldn't have to split the window. I will make this change if others
think it is a good idea.

 > The GDB default is 24 lines, and I had no terminfo entry for dumb,
 > hence GDB uses 24.  Adding a terminfo solves that.  But if gdba
 > requires a specific height, can it not do that as the first command
 > to GDB by itself?  Just a thought.

I will do this. I hadn't realised there was a problem before.

 > Another thing you should look at is starting gdba, stopping GDB
 > and killing the buffer, then starting gdba again.  It does funny
 > things, ...

Please don't simply kill the buffer. Always type gdb-quit before starting a new
session. I'm writing documentation to say things like that and I will try to
make it more robust with time.

Nick

Re: Toolbar problems with GDB mode.

[Jan D.]

lördagen den 4 januari 2003 kl 20.54 skrev Nick Roberts:

>
>> Okay, but it is also the one thing i dislike with DDD for example.
>> In embedded development, one does not even have a main.  DDD then
>> loads a random file, which is annoying as it takes time.
>
> Do you use emacs for embedded development ? If so, could you please tell 
> me
> what gdba does ?

I suspect I can't try that if gdba relies on -annotate=2, since the gdb
version is specially compiled for the communication to the remote target.
That gdb version is quite old, 4.18 or something like that.  But I can try.

	Jan D.

Re: Toolbar problems with GDB mode.

[Kevin Rodgers]

Nick Roberts wrote:

>  > Okay, but it is also the one thing i dislike with DDD for example.
>  > In embedded development, one does not even have a main.  DDD then
>  > lo
>  > Another thing you should look at is starting gdba, stopping GDB
>  > and killing the buffer, then starting gdba again.  It does funny
>  > things, ...
> 
> Please don't simply kill the buffer. Always type gdb-quit before starting a new
> session. I'm writing documentation to say things like that and I will try to
> make it more robust with time.


Could you install a local kill-buffer-hook to handle that for users like Jan?

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Toolbar problems with GDB mode.

[Nick Roberts]

Kevin Rodgers writes:
 
 > > Please don't simply kill the buffer. Always type gdb-quit before starting
 > > a new session. I'm writing documentation to say things like that and I
 > > will try to make it more robust with time.

 > Could you install a local kill-buffer-hook to handle that for users like Jan?

Yes. I think this works best. I was trying to put it in gud-sentinel which is
called every time the process state changes. However, this is after the GUD
buffer is killed which makes it difficult to distinguish between gdb and gdba.

kill-buffer-hook won't work if the user types quit in the GUD buffer but this
probably doesn't matter as quit doesn't make much sense here and just leaves a
dead buffer lying around.

How about:

(defun gud-kill-buffer-hook ()
  (if (eq (current-buffer) gud-comint-buffer)
      (cond ((eq gud-minor-mode 'gdba)
	     (gdb-delete-frames '())
	     (dolist (buffer (buffer-list))
	       (if (not (eq buffer gud-comint-buffer))
		   (save-excursion
		     (set-buffer buffer)
		     (if (eq gud-minor-mode 'gdba)
			 (if (string-match "^\*.+*$" (buffer-name))
			     (kill-buffer nil)
			   (if (display-graphic-p)
			       (remove-images (point-min) (point-max))
			     (remove-strings (point-min) (point-max)))
			   (setq left-margin-width 0)
			   (setq gud-minor-mode nil)
			   (kill-local-variable 'tool-bar-map)
			   (setq gud-running nil)
			   (if (get-buffer-window (current-buffer))
			       (set-window-margins (get-buffer-window
						    (current-buffer))
						   left-margin-width
						   right-margin-width))))))))
	    (t (dolist (buffer (buffer-list))
		 (if (not (eq buffer gud-comint-buffer))
		     (save-excursion
		       (set-buffer buffer)
		       (when gud-minor-mode
			 (setq gud-minor-mode nil)
			 (kill-local-variable 'tool-bar-map)))))))))

(add-hook 'kill-buffer-hook 'gud-kill-buffer-hook)

Re: Toolbar problems with GDB mode.

[Jan D.]

>>> Please don't simply kill the buffer. Always type gdb-quit before starting
>>> a new session. I'm writing documentation to say things like that and I
>>> will try to make it more robust with time.
>
>> Could you install a local kill-buffer-hook to handle that for users like 
>> Jan?
>
> Yes. I think this works best. I was trying to put it in gud-sentinel which 
> is
> called every time the process state changes. However, this is after the GUD
> buffer is killed which makes it difficult to distinguish between gdb and 
> gdba.
>
> kill-buffer-hook won't work if the user types quit in the GUD buffer but 
> this
> probably doesn't matter as quit doesn't make much sense here and just 
> leaves a
> dead buffer lying around.

Actually it does make sense.  To reconnect to an embedded target, it is
convinient to quit the debugger and later restart it.  If one is
debugging something difficult, keeping output from previous sessions
in the gdb buffer is helpful.

Note, it is usually not a quit followed directly after a restart,
but rather quit, edit some files, compile, upload new loadmodule to
the target, reboot the target, restart debugger.

Can't you both have it in a buffer delete hook and in the sentinel?

BTW, starting gdba on my embedded target which doesn't have a main
does not load any files.  It works just like M-x gdb.

	Jan D.

Re: Toolbar problems with GDB mode.

[Nick Roberts]

 > Actually it does make sense.  To reconnect to an embedded target, it is
 > convinient to quit the debugger and later restart it.  If one is
 > debugging something difficult, keeping output from previous sessions
 > in the gdb buffer is helpful.
 > 
 > Note, it is usually not a quit followed directly after a restart,
 > but rather quit, edit some files, compile, upload new loadmodule to
 > the target, reboot the target, restart debugger.
 > 
 > Can't you both have it in a buffer delete hook and in the sentinel?

I can use a local kill-buffer-hook to record gud-minor-mode type and then
reset things in gud-sentinel. This seems to do everything you want.
I will install these changes unless someone objects. 

Nick

gdb-ui.el - (gdb-quit) Remove.
	    (gdb-reset) New function.

(defun gdb-reset ()
  "Exit a debugging session cleanly by killing the gdb buffers and resetting
 the source buffers."
  (gdb-delete-frames '())
  (dolist (buffer (buffer-list))
    (if (not (eq buffer gud-comint-buffer))
	(save-excursion
	  (set-buffer buffer)
	  (if (eq gud-minor-mode 'gdba)
	      (if (string-match "^\*.+*$" (buffer-name))
		  (kill-buffer nil)
		(if (display-graphic-p)
		    (remove-images (point-min) (point-max))
		  (remove-strings (point-min) (point-max)))
		(setq left-margin-width 0)
		(setq gud-minor-mode nil)
		(kill-local-variable 'tool-bar-map)
		(setq gud-running nil)
		(if (get-buffer-window (current-buffer))
		    (set-window-margins (get-buffer-window
					 (current-buffer))
					left-margin-width
					right-margin-width))))))))

gud.el - (gud-sentinel) Reset buffers.
         (gud-reset) New function.
	 (gud-kill-buffer-hook) New function.

--- gud.el.~1.170.~	Sun Dec 22 00:01:30 2002
+++ gud.el	Fri Jan 10 21:36:06 2003
@@ -2427,10 +2427,17 @@
 	 ;; buffer killed
 	 ;; Stop displaying an arrow in a source file.
 	 (setq overlay-arrow-position nil)
-	 (set-process-buffer proc nil))
+	 (set-process-buffer proc nil)
+	 (if (eq gud-minor-mode-type 'gdba)
+	     (gdb-reset)
+	   (gud-reset)))
 	((memq (process-status proc) '(signal exit))
 	 ;; Stop displaying an arrow in a source file.
 	 (setq overlay-arrow-position nil)
+	 (with-current-buffer gud-comint-buffer
+	   (if (eq gud-minor-mode 'gdba)
+	       (gdb-reset)
+	     (gud-reset)))
 	 (let* ((obuf (current-buffer)))
 	   ;; save-excursion isn't the right thing if
 	   ;;  process-buffer is current-buffer
@@ -2455,6 +2462,23 @@
 	     ;; Restore old buffer, but don't restore old point
 	     ;; if obuf is the gud buffer.
 	     (set-buffer obuf))))))
+
+(defvar gud-minor-mode-type nil)
+
+(defun gud-kill-buffer-hook ()
+  (if gud-minor-mode
+      (setq gud-minor-mode-type gud-minor-mode)))
+
+(add-hook 'kill-buffer-hook 'gud-kill-buffer-hook)
+
+(defun gud-reset ()
+  (dolist (buffer (buffer-list))
+    (if (not (eq buffer gud-comint-buffer))
+	(save-excursion
+	  (set-buffer buffer)
+	  (when gud-minor-mode
+	    (setq gud-minor-mode nil)
+	    (kill-local-variable 'tool-bar-map))))))
 
 (defun gud-display-frame ()
   "Find and obey the last filename-and-line marker from the debugger.

Re: Toolbar problems with GDB mode.

[Richard Stallman]

    I see that the GUD menu also hangs around after quitting gdb.

Is this menu defined in a local map or a in the global map?  In other
words, is this a bug in GUD or a bug in Emacs' handling of menus?

Re: Toolbar problems with GDB mode.

[Nick Roberts]

 > Is this menu defined in a local map or a in the global map?  In other
 > words, is this a bug in GUD or a bug in Emacs' handling of menus?

Its on the local map (gud-minor-map). I think the patch below is the right fix
for `M-x gdb' as toolbar and menubar are reset if the user kills the GUD
buffer or types quit there. If you agree, I will install it after making
further changes so that it works for `M-x gdba' too.

Nick

--- gud.el.~1.170.~	Sun Dec 22 00:01:30 2002
+++ gud.el	Sun Jan  5 23:07:43 2003
@@ -2423,6 +2423,12 @@
 	      (gud-filter proc ""))))))
 
 (defun gud-sentinel (proc msg)
+  (dolist (buffer (buffer-list))
+    (save-excursion
+      (set-buffer buffer)
+      (when gud-minor-mode
+	(setq gud-minor-mode nil)
+	(kill-local-variable 'tool-bar-map))))
   (cond ((null (buffer-name (process-buffer proc)))
 	 ;; buffer killed
 	 ;; Stop displaying an arrow in a source file.

Re: Toolbar problems with GDB mode.

[Stefan Monnier]

> +    (save-excursion
> +      (set-buffer buffer)

Aka `with-current-buffer'.


	Stefan

Re: Toolbar problems with GDB mode.

[Nick Roberts]

 > > +    (save-excursion
 > > +      (set-buffer buffer)
 > 
 > Aka `with-current-buffer'.

When I replaced functions like insert-buffer with insert-buffer-substring, I
noticed that (besides not clobbering the mark) I was replacing a compiled lisp
function with one that was built-in. This presumably had a speed advantage.

with-current-buffer is `just a macro' (for the above construction) as is
dolist (which I have used, so you can teach an old dog *some* new tricks)
so presumably there is no speed advantage. Looking at dolist it might even be
slower. Would it make sense for someone (more clever than me) to re-write
these as built-in functions ?

Nick

Re: Toolbar problems with GDB mode.

[Stefan Monnier]

>  > > +    (save-excursion
>  > > +      (set-buffer buffer)
>  > Aka `with-current-buffer'.
> with-current-buffer is `just a macro' (for the above construction) as is

No, it uses `save-current-buffer' rather than `save-excursion'.


	Stefan

Re: Toolbar problems with GDB mode.

[Eli Zaretskii]

> From: Nick Roberts <nick@nick.uklinux.net>
> Date: Fri, 3 Jan 2003 20:05:15 +0000
> 
> I'm guessing, but I bet most
> people on this list use gdb from the command line when they debug emacs.

Actually, I'm using "M-x gdb" whenever I possibly can (some platforms
I work on don't support GUD).  However, I do find myself typing GDB
commands into the GUD buffer directly rather than clicking on the tool
bar.

Re: Toolbar problems with GDB mode.

[Jan D.]

> > I'm guessing, but I bet most
> > people on this list use gdb from the command line when they debug emacs.
> 
> Actually, I'm using "M-x gdb" whenever I possibly can (some platforms
> I work on don't support GUD).  However, I do find myself typing GDB
> commands into the GUD buffer directly rather than clicking on the tool
> bar.

I use the toolbar, I think it is a good addition.  When I wan't to
get a good overview of the source, I can hide the gdb buffer and
use the toolbar to step.  Somehow I find that more convinient
than doing C-x C-a C-n and friends.

	Jan D.