asynchronous MI output commands

> > > For the record, that's basically what I have
in KDevelop. There's
> command
> > > queue, and commands are sent to gdb
one-at-a-time, and responses come
> > > exactly in the same order. Remembering the
last issued command (i.e.
> > > instance of GDBCommand class internal to
KDevelop) makes it possible
> to
> > > route the response back to the original
command.
> > >
> > > I'm don't quite understand the problems
being discussed in this
> thread.
> > > It's
> > > not apparent why one has to know the type of
the last command while
> > > parsing, and if so, why remembering the last
command is bad idea.
> > >
> > > It's hard to believe that response from MI
can be useful without
> knowing
> > > the
> > > last issued command. Say, response from
-data-evaluate-expression is
> > > useless if you don't know what part of
frontend wants that data --
> > > evaluating expression is used in many use
cases. So, you need to
> associate
> > > extra data with commands anyway.
> > >
> >
> > I agree, the example that comes to my mind is
"next", "step",
"finish",
> > "continue" etc ...  To do some
optimization front-ends will probably
> need to
> > know the last command issue (for example clearing
all the variable state
> in
> > a variable view for "continue").
> 
> I see the point, however, how do you know if the user
typed continue? I
> allow the user to have access to the console, and by
doing so, I can't
> make any assumptions on what GDB is doing.
> 

I suppose you could intercept the CLI commands before
sending it to GDB

> > Maybe I'm mistaken but I have the impression,
looking at the thread,
> some
> > folks are confusing OOB and synchronous response
that comes after
> issuing a
> > command.
> 
> I'm hopefull not confusing them, but maybe. For
synchronous commands, I
> just think it's a little ugly that you need the MI
input command to
> determine what an MI output command is.
> 

You can certainly parse the MI output without knowing what
the input was.
The problem is when you get answer what do you do with it? 
For example
-data-evaluate-expression may be an action for hovering or
to update a tree
viewer etc... Most commands are "synchronous"
i.e. an answered to a
question.  Usually front ends will have callbacks attach to
the MI
question/command.


> For asynchronous commands, there is simply no way to
know what you are
> looking at AFAIK. You just have to poke around until
your fingers get
> tired. I still need to research this more though.
> 

OOB were suppose to be a way for GDB to notify of changes,
that did not come
from a user action. Comes to mind hitting a breakpoint,
thread creation,
loading of a library, etc...

> Bob Rossi

On Thu, May 11, 2006 at 10:58:08AM -0400, Alain Magloire
wrote:
> 
> 
> > > > For the record, that's basically what I
have in KDevelop. There's
> > command
> > > > queue, and commands are sent to gdb
one-at-a-time, and responses come
> > > > exactly in the same order. Remembering
the last issued command (i.e.
> > > > instance of GDBCommand class internal to
KDevelop) makes it possible
> > to
> > > > route the response back to the original
command.
> > > >
> > > > I'm don't quite understand the
problems being discussed in this
> > thread.
> > > > It's
> > > > not apparent why one has to know the
type of the last command while
> > > > parsing, and if so, why remembering the
last command is bad idea.
> > > >
> > > > It's hard to believe that response from
MI can be useful without
> > knowing
> > > > the
> > > > last issued command. Say, response from
-data-evaluate-expression is
> > > > useless if you don't know what part of
frontend wants that data --
> > > > evaluating expression is used in many
use cases. So, you need to
> > associate
> > > > extra data with commands anyway.
> > > >
> > >
> > > I agree, the example that comes to my mind is
"next", "step",
"finish",
> > > "continue" etc ...  To do some
optimization front-ends will probably
> > need to
> > > know the last command issue (for example
clearing all the variable state
> > in
> > > a variable view for "continue").
> > 
> > I see the point, however, how do you know if the
user typed continue? I
> > allow the user to have access to the console, and
by doing so, I can't
> > make any assumptions on what GDB is doing.
> > 
> 
> I suppose you could intercept the CLI commands before
sending it to GDB

This isn't a good idea, and probably impossible. Don't
forget about user
defined commands. Also, don't forget that hitting a
breakpoint can run
some commands. You never really know when 'continue' is
sent.

> > > Maybe I'm mistaken but I have the
impression, looking at the thread,
> > some
> > > folks are confusing OOB and synchronous
response that comes after
> > issuing a
> > > command.
> > 
> > I'm hopefull not confusing them, but maybe. For
synchronous commands, I
> > just think it's a little ugly that you need the
MI input command to
> > determine what an MI output command is.
> > 
> 
> You can certainly parse the MI output without knowing
what the input was.
> The problem is when you get answer what do you do with
it?  

Yes, sorry this is what I mean. Geez, I'm not good at
expressing myself.

> For example
> -data-evaluate-expression may be an action for hovering
or to update a tree
> viewer etc... Most commands are
"synchronous" i.e. an answered to a
> question.  Usually front ends will have callbacks
attach to the MI
> question/command.
> 
> 
> > For asynchronous commands, there is simply no way
to know what you are
> > looking at AFAIK. You just have to poke around
until your fingers get
> > tired. I still need to research this more though.
> > 
> 
> OOB were suppose to be a way for GDB to notify of
changes, that did not come
> from a user action. Comes to mind hitting a breakpoint,
thread creation,
> loading of a library, etc...

I need to play more with these. Thanks for the suggestions.

Bob Rossi

I think that the lack of notification about what has gone on
when  
somebody uses interpreter-exec to run the target is just a
bug in the  
interpreter-exec command.  Since that command allows lots of
stuff to  
go on behind the MI client's back, you need to inform the
client  
about this.  You could either post asynchronous
notifications about  
what happened (for instance an =running or whatever) or you
can just  
make the -interpreter-exec command behave like -exec-next
when it  
does indeed run the target.  The latter is what we did for
Xcode, so  
you get the *stopped message if the target was run.

Jim



On May 11, 2006, at 8:02 AM, Bob Rossi wrote:

>>>> I agree, the example that comes to my mind
is "next", "step",  
>>>> "finish",
>>>> "continue" etc ...  To do some
optimization front-ends will  
>>>> probably
>>> need to
>>>> know the last command issue (for example
clearing all the  
>>>> variable state
>>> in
>>>> a variable view for
"continue").
>>>
>>> I see the point, however, how do you know if
the user typed  
>>> continue? I
>>> allow the user to have access to the console,
and by doing so, I  
>>> can't
>>> make any assumptions on what GDB is doing.
>>>
>>
>> I suppose you could intercept the CLI commands
before sending it  
>> to GDB
>
> This isn't a good idea, and probably impossible.
Don't forget about  
> user
> defined commands. Also, don't forget that hitting a
breakpoint can run
> some commands. You never really know when 'continue'
is sent.
>

On Thu, May 11, 2006 at 08:42:03AM -0700, Jim Ingham wrote:
> I think that the lack of notification about what has
gone on when  
> somebody uses interpreter-exec to run the target is
just a bug in the  
> interpreter-exec command.  Since that command allows
lots of stuff to  
> go on behind the MI client's back, you need to inform
the client  
> about this.  You could either post asynchronous
notifications about  
> what happened (for instance an =running or whatever) or
you can just  
> make the -interpreter-exec command behave like
-exec-next when it  
> does indeed run the target.  The latter is what we did
for Xcode, so  
> you get the *stopped message if the target was run.

This is a topic I'd like to see a single consensus on,
sometime soon.
I have an ulterior motive.

I wrote, some time ago, patches to use Guile to implement
GDB CLI
commands.  It works by, roughly, opening a bidirectional MI
channel to
Guile, and temporarily suspending the CLI channel.  But if
the front
end in use is MI, what notifications should that frontend
get?  Should
it be told the target is running, even if e.g. the user
defined command
just calls a function in the target?  Should the Guile
interpreter get
notifications when the user or MI client does something?

Basically, I think that getting this right requires multiple
interpreters live at the same time.

I'd like to come back to that code someday.  And,
preferably, merge
Perl and Python support also.  Kip Macy posted Perl bindings
and the
Python ones would be easy to write, now that I know Python -
in fact
it's the only one out of the three I'd be comfortable
doing myself,
the Guile bits were very skeletal.

-- 
Daniel Jacobowitz
CodeSourcery

On May 11, 2006, at 9:22 AM, Daniel Jacobowitz wrote:

> On Thu, May 11, 2006 at 08:42:03AM -0700, Jim Ingham
wrote:
>> I think that the lack of notification about what
has gone on when
>> somebody uses interpreter-exec to run the target is
just a bug in the
>> interpreter-exec command.  Since that command
allows lots of stuff to
>> go on behind the MI client's back, you need to
inform the client
>> about this.  You could either post asynchronous
notifications about
>> what happened (for instance an =running or
whatever) or you can just
>> make the -interpreter-exec command behave like
-exec-next when it
>> does indeed run the target.  The latter is what we
did for Xcode, so
>> you get the *stopped message if the target was run.
>
> This is a topic I'd like to see a single consensus on,
sometime soon.
> I have an ulterior motive.
>
> I wrote, some time ago, patches to use Guile to
implement GDB CLI
> commands.  It works by, roughly, opening a
bidirectional MI channel to
> Guile, and temporarily suspending the CLI channel.  But
if the front
> end in use is MI, what notifications should that
frontend get?  Should
> it be told the target is running, even if e.g. the user
defined  
> command
> just calls a function in the target?  Should the Guile
interpreter get
> notifications when the user or MI client does
something?

>
> Basically, I think that getting this right requires
multiple
> interpreters live at the same time.
>

I'm not sure I understand the design.  Does the user have
access both  
to the MI channel (presumably through the Guile interface)
and to the  
normal gdb CLI interpreter?  That does sound like it would
be hard to  
get right...

In our case, we funnel all access to the CLI through the
-interpreter- 
exec command.  So we do need to be careful that the
-interpreter-exec  
wrapper arranges to tell the MI about all the things that
the CLI  
command might do (including setting breakpoints, changing
the frame,  
running the target, etc).  But I don't think the Xcode
design  
requires two interpreters live simultaneously, it just
requires that  
the notification hooks be sufficient for the purposes.

BTW, we don't notify the UI that the target has run if you
just call  
a function.  Maybe we should so the UI could better figure
out what  
is going on if a user called function stalls for some
reason, but it  
makes the UI's life simpler if it doesn't know about this.

Jim

> I'd like to come back to that code someday.  And,
preferably, merge
> Perl and Python support also.  Kip Macy posted Perl
bindings and the
> Python ones would be easy to write, now that I know
Python - in fact
> it's the only one out of the three I'd be comfortable
doing myself,
> the Guile bits were very skeletal.
>
> -- 
> Daniel Jacobowitz
> CodeSourcery

On Thu, May 11, 2006 at 08:42:03AM -0700, Jim Ingham wrote:
> I think that the lack of notification about what has
gone on when  
> somebody uses interpreter-exec to run the target is
just a bug in the  
> interpreter-exec command.  Since that command allows
lots of stuff to  
> go on behind the MI client's back, you need to inform
the client  
> about this.  You could either post asynchronous
notifications about  
> what happened (for instance an =running or whatever) or
you can just  
> make the -interpreter-exec command behave like
-exec-next when it  
> does indeed run the target.  The latter is what we did
for Xcode, so  
> you get the *stopped message if the target was run.

Hi Jim,

Well, I agree that this is a bug in the interpreter-exec
command.
I think both of your solution are appropriate. I would find
it
interesting to know which solution is easier to implement in
GDB. The
interesting case of course is when the user does a single
CLI command
that is a 'commands' definition. Thus, a single
-interpreter-exec 
command can be similar to running N CLI commands.

I haven't even tested this case out yet, but I'm assuming
there's big
problems in this area. I seem to have more time lately, and
would like
to start patching up some of these holes. I would very much
like to see
mi3 come out soon, with a lot of these problems resolved.

Thanks,
Bob Rossi

On May 11, 2006, at 10:03 AM, Bob Rossi wrote:

> On Thu, May 11, 2006 at 08:42:03AM -0700, Jim Ingham
wrote:
>> I think that the lack of notification about what
has gone on when
>> somebody uses interpreter-exec to run the target is
just a bug in the
>> interpreter-exec command.  Since that command
allows lots of stuff to
>> go on behind the MI client's back, you need to
inform the client
>> about this.  You could either post asynchronous
notifications about
>> what happened (for instance an =running or
whatever) or you can just
>> make the -interpreter-exec command behave like
-exec-next when it
>> does indeed run the target.  The latter is what we
did for Xcode, so
>> you get the *stopped message if the target was run.
>
> Hi Jim,
>
> Well, I agree that this is a bug in the
interpreter-exec command.
> I think both of your solution are appropriate. I would
find it
> interesting to know which solution is easier to
implement in GDB. The
> interesting case of course is when the user does a
single CLI command
> that is a 'commands' definition. Thus, a single
-interpreter-exec
> command can be similar to running N CLI commands.

We seem to get it half right for defined commands.  For
instance:

(gdb) list main
1       int main (int argc, char **argv)
2       {
3
4         printf ("I got %d arguments\n",
argc);
5
6         return 0;
7       }
(gdb) break 4
Breakpoint 1 at 0x2cdc: file main.c, line 4.
(gdb) break 6
Breakpoint 2 at 0x2cec: file main.c, line 6.
(gdb) define printAndContinue
Type commands for definition of
"printandcontinue".
End with a line saying just "end".
 >print argc
 >continue
 >end
(gdb) run
Starting program: /private/tmp/a.out
Reading symbols for shared libraries . done

Breakpoint 1, main (argc=1, argv=0xbffff404) at main.c:4
4         printf ("I got %d arguments\n",
argc);
(gdb) set interpreter mi
-interpreter-exec console-quoted printAndContinue
~"$1 = 1"
~"\n"
^continuing
I got 1 arguments
~"\nBreakpoint "
~"2, main (argc=1, argv=0xbffff404) at
main.c:6\n"
~"6\t  return 0;\n"
^done,MI_HOOK_RESULT= 
{HOOK_TYPE="frame_changed",frame="0"
},MI_HOOK_RESULT= 
{HOOK_TYPE="stack_changed"}

Normally the "I got 1 arguments" line would go
to the tty for the  
target, so that wouldn't show up in the output that the MI
client  
would be parsing.

What we do here is emit the "^continuing" so the
MI can know that the  
target started.  This might more properly be an
"=running" or  
something like that.  I think this is just an artifact of
how the mi  
works right now.

Then when the defined command stops, we tell the MI what has
changed  
in these HOOK_RESULT output messages.  Again, it's arguable
that  
these should also be "=" type messages.  When I
started working on  
this Xcode (ProjectBuilder as it then was) was not good at
handling  
the "=" type asynchronous messages, and I
haven't gotten around to  
changing this.

You don't get a *stopped message because the continuation
is buried  
in the defined command.  We could fix this, and if the
target has run  
tell the client that it has indeed stopped.  But this may
also be an  
argument that it's better to tell the client about this
through the  
asynchronous "=" messages, especially since the
define command could  
run a number of times, and end up with a command that
doesn't run the  
target.

Anyway, what we have now works well enough, if a little
irregular,  
and I don't think fixing it up to be nicer looking would be
 
particularly hard to do.

Note that breakpoint commands can also be a problem here,
since they  
can run console commands out from under the MI.  They can in
fact  
cause the target to stop, print some stuff, then continue
again.  So  
if you allow this - which we had a lot of pressure to do
since  
breakpoint commands are pretty handy - you have to do a
little  
fiddling to get that right as well.

Jim

>
> I haven't even tested this case out yet, but I'm
assuming there's big
> problems in this area. I seem to have more time lately,
and would like
> to start patching up some of these holes. I would very
much like to  
> see
> mi3 come out soon, with a lot of these problems
resolved.
>
> Thanks,
> Bob Rossi