Re: GDB/MI revisited

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

 > >  > 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".
 > 
 > I would recommend this aproach.
 > 
 > Provides a path to a more incremental migration aproach.  MI can be 
 > exploited where it provides the greatest benefit.
 > 
 > It also avoids an immediate rewrite of things like the conosle and 
 > target I/O code.

I would prefer this approach too since the GUD buffer would then allow
completion. However, without level 2 annotations, the CLI is useless to the
lisp package that I have written, so I don't see how an incremental migration
is possible.

 > > 2) Running gdb with GDB/MI (-interp=mi) and accessing CLI using
 > >    "-interpreter-exec console cli-command".
 > 
 > I'd recommend this aproach in new development.
 > 
 > > 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.")
 > 
 > You could even continue to use "run".

Except that the manual says:

   This mechanism is provided as an aid to developers of GDB/MI clients
and not as a reliable interface into the CLI.  Since the command is
being interpreteted in an environment that assumes GDB/MI behaviour,
the exact output of such commands is likely to end up being an
un-supported hybrid of GDB/MI and CLI output.

Also "run" generates ^done rather than *stopped and I am trying to use the
latter to update the source file display.

 > ...
 > To clarify one point.
 > 
 > GDB's biggest concern here isn't with run, et.al.   Rather it is with 
 > the IDEs relying on specific CLI output.  For instance, to obtain the 
 > information needed to display a breakpoint, a non MI IDE would issue a 
 > command such as:...

 > > ...
 > > yypre-prompt-for-continue
 > > ---Type <return> to continue, or q <return> to quit---
 > > yyprompt-for-continue
 > 
 > (I think its funny here that it came back with the prompt - how does an 
 > IDE live with this? :-)

set height 0

 > And then use custom pattern matching to extract the needed information.
 > 
 > If GDB finds it necessary to modify the breakpoint output (add an extra 
 > field, ...) it will likely break the GUIs that are dependant on it. 
 > This is bad since it inhibits GDB's ability to evolve it's user 
 > interface(1).
 > 
 > On the other hand, if an MI command is used vis:...
 > 
 > ...
 > While unreadable to the naked eye it is easily parsable by software. 
 > Further, since the gdb.mi/* testsuite is testing this behavior the 
 > likelyhood of unintentional breakage is lessened (of course the MI 
 > interface will evolve, but the evolution can be managed).

Yes. I follow this.

 > > 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.
 > 
 > You mean something like:
 > 
 > -interpreter-exec console break foo
 > ~Breakpoint 1 created.
 > =breakpoint-create,breakpoint={nr=5,location=foo,file=bar.c,line=47}

I was thinking explicitly of *stopped. I haven't found a need for the others
yet.

 > That is the second change sitting on the interpreters branch.  

I've checked out interps-20030202-branch. This doesn't seem to do the above.
Should I have a different version? Does it generate the *stopped record in
the manner that I would like? Does it work with interpreter mi mi-command
also?

 > I don't think it is immediatly necessary though as the imediate objective
 > is to just address the problem of level two annotations littered through
 > out things like the breakpoint code.

I don't follow. Aren't they interconnected? I thought the idea was that the
quicker that MI got adopted the quicker level two annotations could be dropped

Nick