Re: Multiple debugging sessions

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> Nick Roberts <address@hidden> writes:
>
>> I was aware of the issue. The file gdba.el, which I used as my
>> starting point, used many buffer local variables, presumably to
>> allow multiple sessions.  It didn't work, so I made them global.
>
> Indeed, buffer-local-variables (in source buffers) typically don't
> help if the same file/buffer is shared between multiple debugging
> sessions.

The way to do that would be to have the source buffers contain a
buffer-local variable pointing to the current debugger buffer, and
maintain all important state in buffer-local variables there.

This does not cater for multiple gdb sessions, but you can do this
somehat like that even in the most complicated cases:

(defmacro with-current-gdb-buffer (&rest form)
  `(progn (while (and gdb-session-buffers
                      (null (buffer-name (car gdb-session-buffers))))
             (pop gdb-session-buffers))
          (unless gdb-session-buffers
             (error "No GDB session active"))
          (with-current-buffer (car gdb-session-buffers) ,@form)))

You would then get and set variables wrapped with
with-current-gdb-buffer in order to fetch the buffer-local settings
from the session.

The above loop and check may be unnecessary if gdb-session-buffers is
normally maintained by the proper buffer deletion hooks in the gdb
buffers.  There would be commands to change the "current gdb session"
in a source file if there were more than one around.  I don't think
that they would often be needed.  An active gdb session would push its
position in the gdb-session-buffers variable of an accessed buffer to
the front.

This would almost always do the right thing and have manual override
where really necessary.

Having a list instead of a single variable actually is only necessary
so that after stepping through one file with one debugger, the
association with the previous debugger is restored.  It would be
tolerable, I think, if instead the association was completely broken
and would have to be reestablished manually (by pressing RET in the
appropriate GDB session buffer or executing a special "select gdb
session" command): that way, the user might not get surprised by
unexpected debug session leftovers suddenly being in control.

In that case, the above macro just becomes

(defmacro with-current-gdb-buffer (&rest forms)
  `(progn
     (unless (and gdb-session-buffer (buffer-name gdb-session-buffer))
        (error "No current gdb session"))
     (with-current-buffer gdb-session-buffer ,@forms)))

In fact, this second approach seems programmatically simpler.  A debug
session leaving a buffer would set its gdb-session-buffer variable to
nil.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum