GDB/MI revisited
Nick Roberts
nick@nick.uklinux.net
Fri Feb 7 20:20:00 GMT 2003
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
More information about the Gdb
mailing list