This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
GDB/MI revisited
- From: Nick Roberts <nick at nick dot uklinux dot net>
- To: gdb at sources dot redhat dot com
- Date: Fri, 7 Feb 2003 20:17:34 +0000
- Subject: GDB/MI revisited
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