Re: GDB/MI revisited

Nick Roberts
2003-02-28T21:35:02Z

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