Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney <ac131313@redhat.com>]

[Did anyone mention that Apple's mail tool is officially weird?]
[was a good holiday]


>> On Wednesday, October 2, 2002, at 08:01  AM, Keith Seitz wrote:
>> 
>>> On Tue, 1 Oct 2002, Jim Ingham wrote:
>>> 
>>> I don't want a tight coupling in TIME, or in the output sequence.  I
>>> want meta-info which tells me with 100% certainty that this result is
>>> the result of command foo, that I sent some time in the past, precisely
>>> so I DON'T have to rely on anything about the sequencing of input or
>>> output to make this connection.
> 
>> 
>> Ok, but this is exactly what I don't understand: what does it matter where
>> the breakpoint comes from? All that matters is that you have issued a
>> command, and you don't do anything out of the normaluntil an event from
>> GDB telling you that it has set a breakpoint. You just sit in your event
>> loop waiting for any event (GUI, paint, GDB, blah blah blah).

> 
> In large part, it is just that if I can track cause & effect unambiguously, everything is much cleaner.  From PB, I issue a command, I want to tick off when that command succeeded, and gather all the data from the result I need.  If I get a note back from gdb saying, "The third command down in the command stream that you issued, here is the result to it." then I can do this without any effort.  However, in your proposed implementation, I have to peer at the command stream and wait both for an anonymous breakpoint created message, and a for the done message (to know things are formally done, and because it would be very dangerous to just toss aside bits of the output stream, since it reduces your chances of catching & handling errors intelligently.)  Then I have to use some smarts to tie the breakpoint created message to the particular message I sent to gdb.  This is harder to do, and fragile.

> In my mind, one of the major advantages of the MI was that it made this tie between the command you sent and the result that came from it explicit and unambiguous.  This was in response to a lot of the pain that we suffered in insight where any random spew from the command line would get itself inserted into the "results" of the command you thought you were executing.  You are breaking this tie by moving the results of a command from the command result to an untagged asynchronous event.  For breakpoints, this is probably just an inconvenience.  But if we follow this as a principle, then in more complex cases, where it is not so easy to tell whether an asynchronous notification arose from a command initiated by the MI, or from some other action we will likely start getting confused again.  For instance, we might have something happening in the target, or some console command, or something more gnarly like the results of a breakpoint command which also continued the target wh
ile you thought it was just running...

You mean like http://sources.redhat.com/gdb/papers/libgdb2/wp/gdbtk2.jpg

There are two things here:

- events
- results

And a question of what, if anything, each should be bound two.

For the case in question, I think you're greatest concern is with 
ensuring that the result of the request is clearly bound to the command 
completion indication.  With that in mind, would something like:

	-breakpoint-create
	=breakpoint-created,....
	=breakpoint-created,....
	^done,breakpoint=1

be reasonable?  It clearly binds the created breakpoint with the request 
while at the same time doesn't treat the creation of this breakpoint any 
different to the creation of any other breakpoint.

I don't know how feasible it is to do this, mind.


 >
 > In short, you are breaking one of the core parts of the MI model, for 
no very apparent reason.  In this case, it might be benign, but it is a 
very useful part of the design, and the reasons for doing it are very weak.

The MI was always going to have events and those events were going to be 
separate from the results.  As a simple example (from the 5.2.1 doco):
http://sources.redhat.com/gdb/download/onlinedocs/gdb_24.html#SEC223

	Command With Side Effects
	-> -symbol-file xyz.exe
	<- *breakpoint,nr="3",address="0x123",source="a.c:123"
	<- (gdb)

[sic - its missing a ^done].  One reason for this separation of event 
and result is that we felt we could see far enough ahead to at least 
realise that the MI would have to handle things like:

	-interpreter cli "break foo"
	=breakpoint-created,...
	^done

or even:

	-interpreter cli "source script"
	=breakpoint-created,...
	=breakpoint-deleted,...
	=running
	^done
	(gdb)
	=stopped,...
	=breakpoint-created,...
	=running
	(gdb)

That is, in the general case, trying to tightly bind MI and events to 
results wasn't going to be possible.

Andrew