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.