GDB/MI revisited

[Nick Roberts <nick@nick.uklinux.net>]

Andrew Cagney writes:

 > Can you post a transcript of a typical EMACS <-> GDB session?

It would depend on the user, of course, but typically GDB commands would be
passed to gdb by two means: explicitly through the GUD buffer or through a
lisp function. The latter could be invoked through the minibuffer, a key sequence
or through the toolbar.

I'm exploring two approaches:

1) Running gdb normally and accessing GDB/MI using "interpreter mi mi-command".

2) Running gdb with GDB/MI (-interp=mi) and accessing CLI using
   "-interpreter-exec console cli-command".

In both cases, the source file display is only updated if commands
are issued through a lisp function. This is because in the first case the lisp
function is bound to an mi command indirectly e.g

(gud-def gud-run    "interpreter mi -exec-run"  nil    "Run the program.")

and in the second case it is bound to one directly e.g 

(gud-def gud-run    "-exec-run"	     nil    "Run the program.")

and these output the out of bound record `*stopped' which emacs can parse for
the program location.

Conversely, in both cases, GDB commands entered through the GUD buffer do not
currently generate `*stopped' and source display is not updated.

QUESTION: Is it possible to modify GDB so that it does generate `*stopped' in
these cases?

The first case would require that a cli command generates out of bound
records. This would require a change in behaviour in gdb so need its own flag
e.g gdb -emacs

The second case would require that "-interpreter-exec console cli-command"
generates out of bound records. This could be its defined behaviour as it
probably would be appropriate to others.

Nick