[MI] -break-insert: (a)synchronous?

[MI] -break-insert: (a)synchronous?

[Keith Seitz]

Hi,

Ok, I believe that there was some general consensus that we want
asynchronus event notifications. Do we also want only one channel for the
notification of these events?

It seems to me that we've got ways to communicate the breakpoint-create
event: events and commands. Right now, -break-insert overrides the event
handlers so that it can grab the data about the breakpoint when it is
created, but inserting a breakpoint via another interpreter (like the
console) will send something slightly different:

(gdb)
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x08075056",func="main",file="../../src/gdb/main.c",line="734",times="0"}
(gdb)
-interpreter-exec console "break captured_main"
During symbol reading, couldn't parse type; debugger out of date?.
During symbol reading, bad structure-type format.
*"breakpoint-create,number=1"
Breakpoint 1 at 0x80743ba: file ../../src/gdb/main.c, line 122.
^done
(gdb)

(Ok, so we could also just add the "bkpt=..." info that is being used in
-break-insert onto this command, but in any case, we get no "event" when
inserting via -break-insert.)

I would prefer that we use only event notifications, of course.

That way, the the UI could call -break-info on these events to collect
the information. This way, I only have to write one parser to deal with this
event. (Actually, if I had to deal with both, I would just grab the
breakpoint number from the output of -break-insert.)

Am I being too aggressive/naive?
Keith

Re: [MI] -break-insert: (a)synchronous?

[Andrew Cagney]

> Hi,
> 
> Ok, I believe that there was some general consensus that we want
> asynchronus event notifications. Do we also want only one channel for the
> notification of these events?
> 
> It seems to me that we've got ways to communicate the breakpoint-create
> event: events and commands. Right now, -break-insert overrides the event
> handlers so that it can grab the data about the breakpoint when it is
> created, but inserting a breakpoint via another interpreter (like the

> (Ok, so we could also just add the "bkpt=..." info that is being used in
> -break-insert onto this command, but in any case, we get no "event" when
> inserting via -break-insert.)
> 
> I would prefer that we use only event notifications, of course.
> 
> That way, the the UI could call -break-info on these events to collect
> the information. This way, I only have to write one parser to deal with this
> event. (Actually, if I had to deal with both, I would just grab the

The command was implemented that way to match its documented spec.  I 
remember wondering about alternate implementations at the time.

Sounds like it is time to either define a new command (not capture the 
events) or change the spec.

Andrew

Re: [MI] -break-insert: (a)synchronous?

[Keith Seitz]

On Thu, 13 Jun 2002, Andrew Cagney wrote:

> The command was implemented that way to match its documented spec.  I
> remember wondering about alternate implementations at the time.
>
> Sounds like it is time to either define a new command (not capture the
> events) or change the spec.

Ok, then I would like to propose that we change the spec to use events and
only events when a command results in some event. This reduces the
redundancy.

I'm working on modifying gdbmi.texinfo, but I am a little confused about
all the stream options:

"*" = "exec-async-output"
"+" = "status-async-output"
"=" = "notify-async-output"

From the manual ([] = my comments):
  o status-async-output contains on-going status information about the
    progess of slow operation. All status output is prefixed by "+".
    [I presume that the biggest client for this is downloading to a target.]
  o exec-async-output contains asynchronous state change on the target
    (stopped, started, disappeared). All Async output is prefixed by "*".
    [This seems to be called only by async target state changes.]
  o notify-async-output contains supplementary information that the client
    should handle (e.g., a new breakpoint information). All notify
    output is prefixed by "=".
    [I don't know where this is used. I am unable to find any references
     to this.]

From the descriptions above, it sounds like event notifications should
occur on the notify-async-output channel, "=".

However, if one reads down to the "Command With Side Effects" section, one
sees:

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

The exact meaning of this example is not really clear to me, but I
presume that it is meant to demonstrate what happens when a breakpoint is
inserted as a result of loading a new symbol file (however that may
occur). In any case, the example is certainly not exec-async-output. In
fact, it is nothing in the MI lingo.

To get the ball rolling on cleaning some of this up, I will submit a patch
which changes (replaces?) the meaning of notify-async-output to include
events in the debugger (breakpoints inserted/deleted/modified,
architecture changes, stack frame changes, switching current thread, etc),
and I will update all the examples.

If someone reads this differently than I do, please speak up.

So, here's how I interpret what should happen:

(gdb)
-break-insert main
=breakpoint-create,number="1"
^done,bkpt=...
(gdb)

(I will also be proposing that we whack the result in this case, since we
will get an event notification, too.)

Keith

Re: [MI] -break-insert: (a)synchronous?

[Andrew Cagney]

> On Thu, 13 Jun 2002, Andrew Cagney wrote:
> 
> 
>> The command was implemented that way to match its documented spec.  I
>> remember wondering about alternate implementations at the time.
>>
>> Sounds like it is time to either define a new command (not capture the
>> events) or change the spec.
> 
> 
> Ok, then I would like to propose that we change the spec to use events and
> only events when a command results in some event. This reduces the
> redundancy.

This means another MI version bump (currently it is on 1).  See how mi0 
vs mi1 was handled (especially in the testsuite).

BTW, there is another necessary interface change lurking in the wings - 
frames need to be changed to lists (dump of frame_id) instead of single 
values - so the version bump is likely a good idea.

How to do it?

I guess prototype the changes with -i=mi2 and then when ready do the 
testsuite suffle for the test cases that are effected.

> I'm working on modifying gdbmi.texinfo, but I am a little confused about
> all the stream options:
> 
> "*" = "exec-async-output"
> "+" = "status-async-output"
> "=" = "notify-async-output"

I don't think there was much checking for compliance of this.

>>From the manual ([] = my comments):
>   o status-async-output contains on-going status information about the
>     progess of slow operation. All status output is prefixed by "+".
>     [I presume that the biggest client for this is downloading to a target.]
>   o exec-async-output contains asynchronous state change on the target
>     (stopped, started, disappeared). All Async output is prefixed by "*".
>     [This seems to be called only by async target state changes.]
>   o notify-async-output contains supplementary information that the client
>     should handle (e.g., a new breakpoint information). All notify
>     output is prefixed by "=".
>     [I don't know where this is used. I am unable to find any references
>      to this.]
> 
>>From the descriptions above, it sounds like event notifications should
> occur on the notify-async-output channel, "=".
> 
> However, if one reads down to the "Command With Side Effects" section, one
> sees:
> 
> -> -symbol-file xyz.exe
> <- *breakpoint,nr="3",address="0x123",source="a.c:123"
> <- (gdb)

I think this is a straight error.

> So, here's how I interpret what should happen:
> 
> (gdb)
> -break-insert main
> =breakpoint-create,number="1"
> ^done,bkpt=...
> (gdb)
> 
> (I will also be proposing that we whack the result in this case, since we
> will get an event notification, too.)

Andrew

Re: [MI] -break-insert: (a)synchronous?

[Keith Seitz]

On Fri, 14 Jun 2002, Andrew Cagney wrote:

> This means another MI version bump (currently it is on 1).  See how mi0
> vs mi1 was handled (especially in the testsuite).

I'll take care of it. Unless I hear otherwise, I will modify the code to
support old and new. Are we going to set a date or time limit on
deprecating the old mis?

> BTW, there is another necessary interface change lurking in the wings -
> frames need to be changed to lists (dump of frame_id) instead of single
> values - so the version bump is likely a good idea.

Yes, indeed. I guess it's a good time to make drastic changes? ;-)

> How to do it?
>
> I guess prototype the changes with -i=mi2 and then when ready do the
> testsuite suffle for the test cases that are effected.

Will do.

Thanks for the note.
Keith

Re: [MI] -break-insert: (a)synchronous?

[Daniel Jacobowitz]

On Fri, Jun 14, 2002 at 10:49:53AM -0700, Keith Seitz wrote:
> On Fri, 14 Jun 2002, Andrew Cagney wrote:
> 
> > This means another MI version bump (currently it is on 1).  See how mi0
> > vs mi1 was handled (especially in the testsuite).
> 
> I'll take care of it. Unless I hear otherwise, I will modify the code to
> support old and new. Are we going to set a date or time limit on
> deprecating the old mis?

Please?  In particular, I don't want us to keep accumulating testsuites
for different protocol versions forever.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [MI] -break-insert: (a)synchronous?

[Andrew Cagney]

> On Fri, Jun 14, 2002 at 10:49:53AM -0700, Keith Seitz wrote:
> 
>> On Fri, 14 Jun 2002, Andrew Cagney wrote:
>> 
> 
>> > This means another MI version bump (currently it is on 1).  See how mi0
>> > vs mi1 was handled (especially in the testsuite).
> 
>> 
>> I'll take care of it. Unless I hear otherwise, I will modify the code to
>> support old and new. Are we going to set a date or time limit on
>> deprecating the old mis?
> 
> 
> Please?  In particular, I don't want us to keep accumulating testsuites
> for different protocol versions forever.

I was thinking of having it release or time limited.  One release may 
not be long enough though.  Mind you, at this stage I'm guessing as 
people using MI haven't got their changes merged in.

Andrew