Re: GDB/MI revisited

[Andrew Cagney <ac131313@redhat.com>]

>  > >  > 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.

Why exactly is it useless?  Using both [deprecated] level 2 annotations 
and "interpreter mi ..." simultaneously.

>  > > 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.

The manual is refering to this behavior:

(gdb)
target sim
&"target sim\n"
~"Connected to the simulator.\n"
^done
(gdb)

The new behavior vis:

(gdb)
-interpreter-exec console "target sim"
~"Connected to the simulator.\n"
^done
(gdb)

is documented and supported.

>  > 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.

To clarify something about level 2 annotations, what exactly is this new 
emacs code dependant on?  For level two annotations the rough equivalent 
to the above is (ignore the yy):

> info break
> 
> yypost-prompt-for-continue
> yyarg-value *
> 0x2000000
> yyarg-end
> , 
> yyarg-begin
> envp
> yyarg-name-end
> =
> yyarg-value *
> 0x20007c4
> yyarg-end
> )
> yyframe-source-begin
>  at 
> yyframe-source-file
> /home/scratch/GDB/src/gdb/testsuite/gdb.base/break.c
> yyframe-source-file-end
> :
> yyframe-source-line
> 75
> yyframe-source-end

and it is these markups that GDB wants to get away from.  They are what 
is littered through out GDB's code and the motivator behind getting rid 
of level two annotations.

>  > 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?

Hmm, so to split this into two problems.  How much of each of:

- markups, as in the above marking up of the breakpoint out
- events, as in things like `*stopped'

is this code dependant on?

>  > 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

The concern is with the marking up of things like breakpoint output. 
Event notification, I believe, is less of a problem.

Andrew