Re: GDB/MI revisited

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

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

Ah! I follow you now. Does this mean that you would like to incrementally
obsolete annotations? This relates to something that I said earlier:

NR> Also gdb-ui.el probably doesn't need all the annotations. If you lost some
NR> key ones (frames-invalid and breakpoints-invalid, for example) would this
NR> make it easier to maintain?

I will give incremental migration some thought but unless the benefits are
clear (for you or me) I think it might be easier to do in one go.

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

OK, but `-interpreter-exec console' run still generates ^done rather than
*stopped so I would need to recognise this.

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

How is info break roughly equivalent to break foo?

 > 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.
 
Yes.  I follow this.

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

The current code (gdb-ui.el) is completely dependent on the markups that
annotations provides. I want the new code to use `*stopped' to update file
display. If this works as I would like (as described above and previously)
then together with the `^done' record it should provide most of the
functionality that Emacs needs.

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

If this is the case, I *think* I could modify gdb-ui.el not to use the
annotation breakpoints-invalid quite easily. I don't know what other users
of level 2 annotations, e.g the authors of cgdb, would think, though.

Nick