This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB/MI revisited
- From: Nick Roberts <nick at nick dot uklinux dot net>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Sun, 2 Mar 2003 23:53:30 +0000
- Subject: Re: GDB/MI revisited
- References: <15940.5214.123419.414411@nick.uklinux.net><3E5CEA03.2070007@redhat.com><15967.54551.724257.774642@nick.uklinux.net><3E616E6D.1080908@redhat.com>
> > 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