This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0
- From: Keith Seitz <keiths at redhat dot com>
- To: Jim Ingham <jingham at apple dot com>
- Cc: Andrew Cagney <ac131313 at redhat dot com>, <gdb-patches at sources dot redhat dot com>
- Date: Tue, 1 Oct 2002 16:42:28 -0700 (PDT)
- Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0
On Tue, 1 Oct 2002, Jim Ingham wrote:
> BTW, I haven't seen the actual change Keith is planning here. Will he
> be sticking the command sequence cookie in the async result? His
> example didn't show the cookies.
For the record, the proposed change would look like:
(gdb)
200-break-insert main
=breakpoint-create,number="1"
200^done
(gdb)
> Seems to me that reporting command results as an async notification
> means that we are breaking the tie between the command and its results.
And is that necessarily bad? (More on my confusion below...)
> It was very nice that I could issue a bunch of commands at some point
> in the GUI code, then at another place gather up the results, and match
> them to the initial commands by using the sequence ID's.
I'm afraid that I'm not following. Could you please expound? Why would
you want a tight coupling of commands and their results? What's wrong with
just issuing a command at GDB and waiting for GDB to tell you that
it's done something? It seems to me that the less serialization that a UI
does, the more time it has to spend in its event loop and the more
responsive it will feel to the user (barring the java way: create a
freakin' thread for everything).
> In the new way of doing things, we have to parse more carefully, and
> assume that the =breakpoint-create that we just got was the one that
> came from the -break-insert in the output just above it. It makes the
> client stream parser have to be more stateful that in the mi0 version,
> which doesn't seem to me all that good an idea. If the async event has
> the cookie in it, this will be a little better, though it still means I
> have a two-step accumulation phase for each command (wait for the async
> result with the right cookie, then the done with the right cookie...)
Ditto the above. Maybe -break-insert and =breakpoint-create are bad
examples(?), but I am not able to imagine why it would matter which
command elicited the notification. Commands are issued, and something
happens. The only case I can imagine where this is important is when
an error occurs setting the breakpoint, but MI will (and will
continue) to report errors immediately.
Maybe something related to async targets? (BTW, there is no reason why
I/we cannot/could not put the old behavior back for an MI0 target, if
'mi0' were sticking around, which is a decision I want nothing to do
with, actually.) One is still pretty screwed, though, when
"interpreter-exec" is used, unless we revert from async notification back
to serial notification via hook hack that you're using.
<devil's advocate>
As far as the versioning thing goes, I must say that I don't really care,
(not that my opinion matters), but I can understand why some on this list
would be less sympathetic with objections to dropping mi0 coming from
Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of
stuff, but only managed to "submit" a giant distribution tarball of their
modified GDB. I wouldn't be too suprised if some thought that Apple was
taking advantage of the public's work. Mind you, I'm not saying that any
of this is true, but I wouldn't be suprised if some one reading this list
felt that way.
</devil's advocate>
Keith