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: Jim Ingham <jingham at apple dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Fri, 25 Oct 2002 18:21:10 -0700
- Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0
Andrew,
On Friday, October 25, 2002, at 05:57 PM,
gdb-patches-digest-help@sources.redhat.com wrote:
From: Andrew Cagney <ac131313@redhat.com>
Date: Fri Oct 25, 2002 2:48:09 PM US/Pacific
To: Jim Ingham <jingham@apple.com>
Cc: Keith Seitz <keiths@redhat.com>, gdb-patches@sources.redhat.com
Subject:
[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 while
you thought it was just running...
You mean like
http://sources.redhat.com/gdb/papers/libgdb2/wp/gdbtk2.jpg
Cute...
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.
Right. I think the principle should be that any command that has a
direct result, that result should be reported in the "done" message of
the command. I don't mind that it also get reported as an event. For
instance, this means that if something like your listing above occurs,
I know that the first breakpoint is the one I intended to make, and the
second one, dunno about. This will be important, for instance, if we
ever teach gdb that breaking on template source code generated a whole
bunch of breakpoints. The GUI will want to gather up these breakpoints
and treat them as a single bundle (since if the source line breakpoint
is deleted in the UI, it will need to delete all these breakpoints).
So knowing that one of the breakpoint-created events is some odd
accident would be useful...
I don't know how feasible it is to do this, mind.
Shouldn't be hard for the breakpoints, we do it already...
>
> 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.
Seems better to say that an mi command will usually have a well defined
result, but may well have unintended consequences as well. We should
be able to bind the result to the command token, but not the unintended
consequences. It's actually not impossible to do that either, the
original implementation that I did had all the event-like things added
as tagged bits to the command result, unless they came after the
command returned. But that's not the way Keith chose to implement it,
which is fine.
Of course, -interpreter-exec (is Keith changing this to -interpreter,
or did you just type it wrong?) has NO well defined results.
Everything is an unintended consequence. For convenience's sake, I
think I report whether the command has started up the inferior or not,
but even that could be gotten from events.
Jim
--
Jim Ingham jingham@apple.com
Developer Tools
Apple Computer