Re: asynchronous MI output commands

Re: asynchronous MI output commands

[Bjarke Viksoe]

>Daniel Jacobowitz wrote:
>
>If I were writing a front-end, I would have an arbitration layer which
>sent questions to GDB and received answers.  The answers will come back
>one at a time, in the same order the questions were asked.  If you send
>two -var-evaluate-expression commands, you'll get back two answers, in
>that same order.
>
>Am I missing something?  Is there a reason that this isn't enough?

No, the abstraction layer is exactly my design - but as I explained: the 
goal of my tool is that it's used over a remote line (eg. SSH over internet) 
where the answer can be a couple of 100ms delayed. It is most desirable to 
be able to send multiple commands and have the front-end digest the answer 
as they slowly arrive - updating the UI in increments.
Yes, my views need to send multiple -var-evaluate-expression and this is the 
reason that I'm forced to restrict the design to what you describe. The 
reason it's not good enough: it so slow.

Because of the latency, my "abstraction layer" runs in its own thread. This 
makes the UI wonderfully responsive, but doesnÂ’t allow a component/view to 
submit a command and read the answer in the same context. Answers arrive out 
of context and are processed separately - creating a high need to know what 
the answer originated from.

bjarke
BVRDE - bvrde.sourceforge.net

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Sun, May 07, 2006 at 11:40:54PM +0200, Bjarke Viksoe wrote:
> >Daniel Jacobowitz wrote:
> >
> >If I were writing a front-end, I would have an arbitration layer which
> >sent questions to GDB and received answers.  The answers will come back
> >one at a time, in the same order the questions were asked.  If you send
> >two -var-evaluate-expression commands, you'll get back two answers, in
> >that same order.
> >
> >Am I missing something?  Is there a reason that this isn't enough?
> 
> No, the abstraction layer is exactly my design - but as I explained: the 
> goal of my tool is that it's used over a remote line (eg. SSH over 
> internet) where the answer can be a couple of 100ms delayed. It is most 
> desirable to be able to send multiple commands and have the front-end 
> digest the answer as they slowly arrive - updating the UI in increments.
> Yes, my views need to send multiple -var-evaluate-expression and this is 
> the reason that I'm forced to restrict the design to what you describe. The 
> reason it's not good enough: it so slow.
> 
> Because of the latency, my "abstraction layer" runs in its own thread. This 
> makes the UI wonderfully responsive, but doesn?t allow a component/view to 
> submit a command and read the answer in the same context. Answers arrive 
> out of context and are processed separately - creating a high need to know 
> what the answer originated from.

Sorry, but I don't feel like you've answered my question.  Why does
this interfere with pipelining?

Thread A:

  - gdb_thread.submit_question("-var-evaluate-expression A")

Thread B:

  - gdb_thread.submit_question("-var-evaluate-expression B")

GDB thread:

  - Send "-var-evaluate-expression A".  Record this as an outstanding
    request.
  - Send "-var-evaluate-expression B".  Record this as an outstanding
    request.
  - Notice that data is available.
  - Parse it, and notice that it is a response to a command.  Take the
    first command off the queue of outstanding requests.  See that it
    is -var-evaluate-expression A.  Return the answer to that request's
    submission object, in whatever way you need to.
  - Notice that more data is available... etc.

If this isn't workable, can you fill in the piece I'm missing?  Why
not?  Each command should generate a single synchronous (^done, ^error)
response.

-- 
Daniel Jacobowitz
CodeSourcery

Re: asynchronous MI output commands

[Bjarke Viksoe]

> > >
> > >If I were writing a front-end, I would have an arbitration layer which
> > >sent questions to GDB and received answers.  The answers will come back
> > >one at a time, in the same order the questions were asked.  If you send
> > >two -var-evaluate-expression commands, you'll get back two answers, in
> > >that same order.
> > >
> > >Am I missing something?  Is there a reason that this isn't enough?
> > ...
> >
> >
> > Because of the latency, my "abstraction layer" runs in its own thread. 
>This
> > makes the UI wonderfully responsive, but doesn?t allow a component/view 
>to
> > submit a command and read the answer in the same context. Answers arrive
> > out of context and are processed separately - creating a high need to 
>know
> > what the answer originated from.
>
>Sorry, but I don't feel like you've answered my question.  Why does
>this interfere with pipelining?
>
>Thread A:
>   - gdb_thread.submit_question("-var-evaluate-expression A")
>Thread B:
>   - gdb_thread.submit_question("-var-evaluate-expression B")
>GDB thread:
>   - Send "-var-evaluate-expression A".  Record this as an outstanding
>     request.
>   - Send "-var-evaluate-expression B".  Record this as an outstanding
>     request.
>   - Notice that data is available.
>   - Parse it, and notice that it is a response to a command.  Take the
>     first command off the queue of outstanding requests.  See that it
>     is -var-evaluate-expression A.  Return the answer to that request's
>     submission object, in whatever way you need to.
>   - Notice that more data is available... etc.
>
>If this isn't workable, can you fill in the piece I'm missing?  Why
>not?  Each command should generate a single synchronous (^done, ^error)
>response.
>

Right. When I was testing all this I ran into more trouble. I would actually 
see something like this:

(gdb) -var-evaluate-expression A
^done,value="12-var-evaluate-expression A
34"
(gdb)
^done,value="1234"

...because of the lack of flow-control in the telnet/SSH session (notice how 
the next command is embedded in the output of the first). This put me back 
to square#1 since there was now no 1:1 relationship between cmd/answ. While 
I agree that your plan is workable, I just concluded that keeping track of a 
command-list wasn't a reliable option without some severe pain when recovery 
was needed (aka back to the <token> option) - and I didn't feel that I was 
getting any closer to having a state-less component.

I would expect that some front-ends (GUI based ones) will employ a similar 
design as mine - even if they are in an environment more attached to their 
GDB - since we've already seen that fireing a backtrace-type command for 
every step can be very slow and would block the UI unreasonably if not 
batched in a thread other than the main GUI one.
My take was that I assumed that the output was more detailed simply because 
it would make my life easier in handling the returned output - instead of 
having to build complex schemes just to call a simple GDB command.

bjarke

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Mon, May 08, 2006 at 12:50:03AM +0200, Bjarke Viksoe wrote:
> Right. When I was testing all this I ran into more trouble. I would 
> actually see something like this:
> 
> (gdb) -var-evaluate-expression A
> ^done,value="12-var-evaluate-expression A
> 34"
> (gdb)
> ^done,value="1234"
> 
> ...because of the lack of flow-control in the telnet/SSH session (notice 
> how the next command is embedded in the output of the first).

Well, that's a whole different problem.  Note that GDB is _not_ echoing
your commands here - it only handles output in MI mode.  The terminal
is doing it.  On Unix systems, you can solve this by running "stty
-echo" (beware, some shells reset this when in interactive mode - my
zsh was eating it, I had to try in bash).

> This put me back to square#1 since there was now no 1:1 relationship
> between cmd/answ.  While I agree that your plan is workable, I just
> concluded that keeping track of a command-list wasn't a reliable
> option without some severe pain when recovery was needed (aka back to
> the <token> option) - and I didn't feel that I was getting any closer
> to having a state-less component.

How would changing the MI output improve this situation at all?  I
can't see it.

-- 
Daniel Jacobowitz
CodeSourcery

MI: anynchronous vs. synchronous

[Vladimir Prus]

Bjarke Viksoe wrote:

>>Daniel Jacobowitz wrote:
>>
>>If I were writing a front-end, I would have an arbitration layer which
>>sent questions to GDB and received answers.  The answers will come back
>>one at a time, in the same order the questions were asked.  If you send
>>two -var-evaluate-expression commands, you'll get back two answers, in
>>that same order.
>>
>>Am I missing something?  Is there a reason that this isn't enough?
> 
> No, the abstraction layer is exactly my design - but as I explained: the
> goal of my tool is that it's used over a remote line (eg. SSH over
> internet) where the answer can be a couple of 100ms delayed. 

I was thinking about this lately. From my experience, anynchronous
communication with gdb inside frontend can be rather inconvenient:

1. Instead of just:

      value = gdb.send_command("-data-evaluate-expression foo")["value"];

you need to use callbacks all over:

    gdb.addCommand("-data-evaluate-expression foo",
                   this,
                   &My_class::handleValue);

which increases the amount of code considerably, and makes following the
logic much harder.

2. The sequence of commands (where second command uses result of first)
becomes tricky to implement. Note only you'll need a callback method for
each command, but you can get undersired interaction with other commands:

     command_1
     some_unrelated_command_that_makes_result_of_command_1_invalid
     command_2_that_uses_no_invalud_result_of_command_1


Because of those issues, for a future version of KDevelop I plan to run
debugger in a separate thread, that can just block while waiting for reply
from gdb. So, there will be no callbacks at all, and the code will be
rather easy to understand, e.g:

   unsigned address = gdb.send_command("-data-evaluate-expression &i")
                                     ["value"].toInt();
   gdb.send_command(QString("-break-watch *%1").arg(address));

On the other hand, this will mean commands are sent one-by-one, so in your 
your 100ms round-trip case, this will be extremely slow. I still think that
given that 100ms links are very uncommon, that would be a right decision in
my case. But any ideas are welcome! 

- Volodya

 

RE: asynchronous MI output commands

[Alain Magloire]

> From: Daniel Jacobowitz [mailto:drow@false.org]
> 
> 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?
> 

IMHO, the MI interpreter should get a notification when the target changes
state from a side effect of CLI commands.  So the example, when the "runs"
command is executed (next, step, call, finish, signal etc...) an OOB should
be drop:
 ^running

Or for example if an external application drops a SIGINT on the inferior, I
do expect a notification. 
 *stopped,...

The GDB CLI channel probably does not need notification because the protocol
was not meant for this but rather a direct access by the users to gdb
commands, strictly query/answers.

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

Is there really a case for this?  The scenario I see is within one
interpreter (say MI), you want to give more power to the users and let them
access advanced gdb commands, so the interpreter-exec provides this nicely.
The only problems is the side effects.  Notification does not have to be
complex, for example something like:
=state_change

Notification, could tell the front end to reload the settings (the
breakpoints, the watchpoints, dlls, etc ...)

> 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.
> 

Re: asynchronous MI output commands

[Jim Ingham]

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

Re: asynchronous MI output commands

[Bob Rossi]

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

Re: asynchronous MI output commands

[Jim Ingham]

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

Re: asynchronous MI output commands

[Daniel Jacobowitz]

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

Re: asynchronous MI output commands

[Jim Ingham]

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.
>

Re: asynchronous MI output commands

[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

RE: asynchronous MI output commands

[Alain Magloire]

> > > 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

Re: asynchronous MI output commands

[Bob Rossi]

On Thu, May 11, 2006 at 03:23:22PM +0400, Vladimir Prus wrote:
> On Thursday 11 May 2006 14:55, Bob Rossi wrote:
> 
> > > > >     const GDBMI::Value& children = r["children"];
> > > > >
> > > > >     for (unsigned i = 0; i < children.size(); ++i)
> > > > >     {
> > > > >         QString exp = children[i]["exp"].literal();
> > > > >
> > > > >
> > > > > If you have specific structures for each response this won't be very
> > > > > much simpler.
> > > >
> > > > Sorry, I've described this before, but apparently not good enough. I
> > > > definatly can create the abstract parse tree with out knowing the input
> > > > command. However, then I want to create C data structures for each
> > > > MI output.
> > >
> > > Why? With C data structures, the above frontend code will be only
> > > marginally simpler.
> >
> > I don't believe that to be the case at all. Look at the C data structure
> > code I have for the -break-list data structure. If a GUI had to use this I
> > think they would be happy.
> 
> So, instead of say:
> 
>     bp["number"].toInt()
> 
> I'd write:
> 
>     bp.number
> 
> ? Well, that's what I call "marginally better". It's better, but not likely to 
> make big practical difference.
> 
> Also, you propose C interface, so is not directly usable in frontend written 
> in C++. Such frontend will likely to have it's own class for breakpoint, and 
> would have to convert from your structure to that class.

Yeah, this will have to happen regardless. I mean, if I only have the
parse tree, it will need to be ported to other languages also. For C++,
it's particular easy, you can either inherit from the struct or use
composition.

> I guess if you want to make MI parser for your own use, any approach is fine. 
> But if you want to make some kind of "standard" MI parser for other frontends 
> to use, I'm not sure that providing such pre-made structures will be a 
> selling point.

Well, I suppose I'll provide them for myself, and others can easily use
the parse tree if that's what they want to do. However, I must warn you,
using the parse tree is more complicated than what you have above. I'm
not exactly sure how you can simply say 
  bp["number"].toInt ()
where does "bp" come from? Is it a pointer into the parse tree? If so,
how did you get to that point?

I have to get the parse tree, which is stored in 'output_ptr' below.
Then i have to get all the way to the result_ptr which has "number" as
the variable. I see you are using a map in C++ which makes the code much
cleaner. I don't have that advantage in C.
  
    gdbmi_result_ptr result_ptr = output_ptr->result_record->result;
    if (strcmp (result_ptr->variable, "BreakpointTable") == 0)
    {
      if (result_ptr->value->value_choice == GDBMI_TUPLE)
      {
	result_ptr = result_ptr->value->option.tuple->result;
	while (result_ptr)
	{
	  if (strcmp (result_ptr->variable, "body") == 0)
	  {
	    if (result_ptr->value->value_choice == GDBMI_LIST)
	    {
	      gdbmi_list_ptr list_ptr = result_ptr->value->option.list;
	      if (list_ptr && list_ptr->list_choice == GDBMI_RESULT)
	      {
		gdbmi_result_ptr result_ptr = list_ptr->option.result;
		while (result_ptr)
		{
		  if (strcmp (result_ptr->variable, "bkpt") == 0)
		  {
		    gdbmi_oc_breakpoint_ptr ptr = create_gdbmi_breakpoint ();

		    gdbmi_value_ptr value_ptr = result_ptr->value;
		    if (value_ptr->value_choice == GDBMI_TUPLE)
		    {
		      gdbmi_result_ptr result_ptr = value_ptr->option.tuple->result;
		      while (result_ptr)
		      {
			if (strcmp (result_ptr->variable, "number") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    char *nstr;
			    if (convert_cstring (result_ptr->value->option.cstring, &nstr) == -1)
			    {
			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
			      return -1;
			    }

			    ptr->number = atoi (nstr);
			    free (nstr);
			    nstr = NULL;
			  }
			} 
			result_ptr = result_ptr->next;
		      }
		    }

		    oc_ptr->input_commands.break_list.breakpoint_ptr =
		       append_gdbmi_breakpoint (oc_ptr->input_commands.break_list.breakpoint_ptr, ptr);
		  }
		  result_ptr = result_ptr->next;
		}
	      }
	    }
	  }
	  result_ptr = result_ptr->next;
	}
      }
    }

> > I do 
> > know that I have some code duplicated that could be in a function, and
> > some other cleanups, but I still think it's far more difficult.
> 
> I think the code you've presented indeed has too much copy-paste. For example:
> 
>  			else if (strcmp (result_ptr->variable, "addr") == 0)
>  			{
>  			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
>  			  {
>  			    if (convert_cstring (result_ptr->value->option.cstring,
>                       &ptr->address) == -1) 
>                   {
>  			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
>  			      return -1;
>  			    }
>  			  }
>  			}
> 
> is a pattern that repeats for many of fields. While in my interface, you'd 
> call:
> 
>    bp["addr"].literal()
> 
> to get exactly same effect. Except that in your code, no error is emitted when 
> "addr" field is not of string type ;-)

I intentionally left out the error. I'm not sure how much error code I
should have in this library if it needs to work in all circumstances.
I'm still thinking about that.

> Maybe if you provide functions  'get_literal' and 'get_integer' and 
> 'get_bool_yn', the size of code can be reduced considerably.

Thanks for the suggestion, I'll try that.

Bob Rossi

Re: asynchronous MI output commands

[Vladimir Prus]

On Thursday 11 May 2006 14:55, Bob Rossi wrote:

> > > >     const GDBMI::Value& children = r["children"];
> > > >
> > > >     for (unsigned i = 0; i < children.size(); ++i)
> > > >     {
> > > >         QString exp = children[i]["exp"].literal();
> > > >
> > > >
> > > > If you have specific structures for each response this won't be very
> > > > much simpler.
> > >
> > > Sorry, I've described this before, but apparently not good enough. I
> > > definatly can create the abstract parse tree with out knowing the input
> > > command. However, then I want to create C data structures for each
> > > MI output.
> >
> > Why? With C data structures, the above frontend code will be only
> > marginally simpler.
>
> I don't believe that to be the case at all. Look at the C data structure
> code I have for the -break-list data structure. If a GUI had to use this I
> think they would be happy.

So, instead of say:

    bp["number"].toInt()

I'd write:

    bp.number

? Well, that's what I call "marginally better". It's better, but not likely to 
make big practical difference.

Also, you propose C interface, so is not directly usable in frontend written 
in C++. Such frontend will likely to have it's own class for breakpoint, and 
would have to convert from your structure to that class.

I guess if you want to make MI parser for your own use, any approach is fine. 
But if you want to make some kind of "standard" MI parser for other frontends 
to use, I'm not sure that providing such pre-made structures will be a 
selling point.

> Look at what I had to do to get the breakpoint structure populated. I
> don't consider this even close to the same complexity as above. 

What do you mean as "above" and why having more complex code is a good thing? 

> I do 
> know that I have some code duplicated that could be in a function, and
> some other cleanups, but I still think it's far more difficult.

I think the code you've presented indeed has too much copy-paste. For example:

 			else if (strcmp (result_ptr->variable, "addr") == 0)
 			{
 			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
 			  {
 			    if (convert_cstring (result_ptr->value->option.cstring,
                      &ptr->address) == -1) 
                  {
 			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
 			      return -1;
 			    }
 			  }
 			}

is a pattern that repeats for many of fields. While in my interface, you'd 
call:

   bp["addr"].literal()

to get exactly same effect. Except that in your code, no error is emitted when 
"addr" field is not of string type ;-)

Maybe if you provide functions  'get_literal' and 'get_integer' and 
'get_bool_yn', the size of code can be reduced considerably.

- Volodya

Re: asynchronous MI output commands

[Bob Rossi]

> > > > > 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.
> > >
> > > What do you mean by "determine what an MI output command is"? You
> > > certainly can parse the response into DOM-like tree without knowing the
> > > output command. If you want to create C data structures for each
> > > response, then yes, you'd need to know the exact type of the last
> > > command. But then, I'm not sure why you want to use C data structures. In
> > > KDevelop, the DOM is fully dynamic and that works just fine, for example:
> > >
> > >     const GDBMI::Value& children = r["children"];
> > >
> > >     for (unsigned i = 0; i < children.size(); ++i)
> > >     {
> > >         QString exp = children[i]["exp"].literal();
> > >
> > >
> > > If you have specific structures for each response this won't be very much
> > > simpler.
> >
> > Sorry, I've described this before, but apparently not good enough. I
> > definatly can create the abstract parse tree with out knowing the input
> > command. However, then I want to create C data structures for each
> > MI output. 
> 
> Why? With C data structures, the above frontend code will be only marginally 
> simpler.

I don't believe that to be the case at all. Look at the C data structure code I 
have for the -break-list data structure. If a GUI had to use this I
think they would be happy.

    enum breakpoint_type
    {
      GDBMI_BREAKPOINT,
      GDBMI_WATCHPOINT
    };

    enum breakpoint_disposition
    {
      GDBMI_KEEP,
      GDBMI_NOKEEP
    };

    struct gdbmi_oc_breakpoint;
    typedef struct gdbmi_oc_breakpoint *gdbmi_oc_breakpoint_ptr;
    struct gdbmi_oc_breakpoint
    {
      int number;
      enum breakpoint_type type;
      enum breakpoint_disposition disposition;
      /* 1 if enabled, otherwise 0 */
      int enabled;
      char *address;
      char *func;
      char *file;
      char *fullname;
      int line;
      int times;

      gdbmi_oc_breakpoint_ptr next;
    };

Look at what I had to do to get the breakpoint structure populated. I
don't consider this even close to the same complexity as above. I do
know that I have some code duplicated that could be in a function, and
some other cleanups, but I still think it's far more difficult.

*Also*, if the MI output changes in some wierd way, the GUI will have to 
code both of these possibilies, instead of just the piece that parses
the MI and stores them into a C data structure. For instance, when MI3
comes out and is potentially not backwards compatible.

    gdbmi_result_ptr result_ptr = output_ptr->result_record->result;
    if (strcmp (result_ptr->variable, "BreakpointTable") == 0)
    {
      if (result_ptr->value->value_choice == GDBMI_TUPLE)
      {
	result_ptr = result_ptr->value->option.tuple->result;
	while (result_ptr)
	{
	  if (strcmp (result_ptr->variable, "body") == 0)
	  {
	    if (result_ptr->value->value_choice == GDBMI_LIST)
	    {
	      gdbmi_list_ptr list_ptr = result_ptr->value->option.list;
	      if (list_ptr && list_ptr->list_choice == GDBMI_RESULT)
	      {
		gdbmi_result_ptr result_ptr = list_ptr->option.result;
		while (result_ptr)
		{
		  if (strcmp (result_ptr->variable, "bkpt") == 0)
		  {
		    gdbmi_oc_breakpoint_ptr ptr = create_gdbmi_breakpoint ();

		    gdbmi_value_ptr value_ptr = result_ptr->value;
		    if (value_ptr->value_choice == GDBMI_TUPLE)
		    {
		      gdbmi_result_ptr result_ptr = value_ptr->option.tuple->result;
		      while (result_ptr)
		      {
			if (strcmp (result_ptr->variable, "number") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    char *nstr;
			    if (convert_cstring (result_ptr->value->option.cstring, &nstr) == -1)
			    {
			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
			      return -1;
			    }

			    ptr->number = atoi (nstr);
			    free (nstr);
			    nstr = NULL;
			  }
			} 
			else if (strcmp (result_ptr->variable, "type") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    if (strcmp (result_ptr->value->option.cstring, "\"breakpoint\"") == 0)
			      ptr->type = GDBMI_BREAKPOINT;
			    else if (strcmp (result_ptr->value->option.cstring, "\"watchpoint\"") == 0)
			      ptr->type = GDBMI_WATCHPOINT;
			  }
			}
			else if (strcmp (result_ptr->variable, "disp") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    if (strcmp (result_ptr->value->option.cstring, "\"keep\"") == 0)
			      ptr->disposition = GDBMI_KEEP;
			    else if (strcmp (result_ptr->value->option.cstring, "\"nokeep\"") == 0)
			      ptr->disposition = GDBMI_NOKEEP;
			  }
			}
			else if (strcmp (result_ptr->variable, "enabled") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    if (strcmp (result_ptr->value->option.cstring, "\"y\"") == 0)
			      ptr->enabled = 1;
			    else
			      ptr->enabled = 0;
			  }
			}
			else if (strcmp (result_ptr->variable, "addr") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    if (convert_cstring (result_ptr->value->option.cstring, &ptr->address) == -1)
			    {
			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
			      return -1;
			    }
			  }
			}
			else if (strcmp (result_ptr->variable, "func") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    if (convert_cstring (result_ptr->value->option.cstring, &ptr->func) == -1)
			    {
			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
			      return -1;
			    }
			  }
			}
			else if (strcmp (result_ptr->variable, "file") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    if (convert_cstring (result_ptr->value->option.cstring, &ptr->file) == -1)
			    {
			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
			      return -1;
			    }
			  }
			}
			else if (strcmp (result_ptr->variable, "fullname") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    if (convert_cstring (result_ptr->value->option.cstring, &ptr->fullname) == -1)
			    {
			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
			      return -1;
			    }
			  }
			}
			else if (strcmp (result_ptr->variable, "line") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    char *nstr;
			    if (convert_cstring (result_ptr->value->option.cstring, &nstr) == -1)
			    {
			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
			      return -1;
			    }

			    ptr->line = atoi (nstr);
			    free (nstr);
			    nstr = NULL;
			  }
			} 
			else if (strcmp (result_ptr->variable, "times") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    char *nstr;
			    if (convert_cstring (result_ptr->value->option.cstring, &nstr) == -1)
			    {
			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
			      return -1;
			    }

			    ptr->times = atoi (nstr);
			    free (nstr);
			    nstr = NULL;
			  }
			} 

			result_ptr = result_ptr->next;
		      }
		    }

		    oc_ptr->input_commands.break_list.breakpoint_ptr =
		       append_gdbmi_breakpoint (oc_ptr->input_commands.break_list.breakpoint_ptr, ptr);
		  }
		  result_ptr = result_ptr->next;
		}
	      }
	    }
	  }
	  result_ptr = result_ptr->next;
	}
      }
    }

Thanks,
Bob Rossi

Re: asynchronous MI output commands

[Vladimir Prus]

On Thursday 11 May 2006 14:40, Bob Rossi wrote:

> > The "continue" command always produces
> >
> >   *stopped
> >
> > response and that's mostly enough for frontend.
>
> OK, this isn't true. I used GDB CVS for this.

Yea, I realized that "continue" not only does not produces "^running" but also 
does not produces "*stopped" right after posting.

> > > > 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.
> >
> > What do you mean by "determine what an MI output command is"? You
> > certainly can parse the response into DOM-like tree without knowing the
> > output command. If you want to create C data structures for each
> > response, then yes, you'd need to know the exact type of the last
> > command. But then, I'm not sure why you want to use C data structures. In
> > KDevelop, the DOM is fully dynamic and that works just fine, for example:
> >
> >     const GDBMI::Value& children = r["children"];
> >
> >     for (unsigned i = 0; i < children.size(); ++i)
> >     {
> >         QString exp = children[i]["exp"].literal();
> >
> >
> > If you have specific structures for each response this won't be very much
> > simpler.
>
> Sorry, I've described this before, but apparently not good enough. I
> definatly can create the abstract parse tree with out knowing the input
> command. However, then I want to create C data structures for each
> MI output. 

Why? With C data structures, the above frontend code will be only marginally 
simpler.

- Volodya

Re: asynchronous MI output commands

[Bob Rossi]

On Thu, May 11, 2006 at 10:08:15AM +0400, Vladimir Prus wrote:
> On Thursday 11 May 2006 06:37, Bob Rossi wrote:
> 
> > > > 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.
> 
> The "continue" command always produces
> 
>   *stopped
> 
> response and that's mostly enough for frontend.

OK, this isn't true. I used GDB CVS for this.

(gdb)
-break-insert main.c:4
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x08048364",func="main",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c",line="4",times="0"}
(gdb)
-break-insert main.c:5
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0804836b",func="main",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c",line="5",times="0"}
(gdb)
-exec-run
^running
(gdb)
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x08048364",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffbc9a4"}],file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c",line="4"}
(gdb)
-interpreter-exec console "continue"
~"Continuing.\n"
~"\n"
~"Breakpoint 2, main (argc=1, argv=0xbffbc9a4) at main.c:5\n"
~"5\t  argc = 2;\n"
^done
(gdb)

The continue command doesn't give a *stopped.

> > > 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.
> 
> What do you mean by "determine what an MI output command is"? You certainly 
> can parse the response into DOM-like tree without knowing the output command.
> If you want to create C data structures for each response, then yes, you'd 
> need to know the exact type of the last command. But then, I'm not sure why 
> you want to use C data structures. In KDevelop, the DOM is fully dynamic and 
> that works just fine, for example:
> 
>     const GDBMI::Value& children = r["children"];
> 
>     for (unsigned i = 0; i < children.size(); ++i)
>     {
>         QString exp = children[i]["exp"].literal();
> 
> 
> If you have specific structures for each response this won't be very much 
> simpler.

Sorry, I've described this before, but apparently not good enough. I
definatly can create the abstract parse tree with out knowing the input
command. However, then I want to create C data structures for each
MI output. I need the MI input command to do that. I was hoping an
extension to the MI output would be allowed to get around this.

> > For asynchronous commands, there is simply no way to know what you are
> > looking at AFAIK. 
> 
> What exactly do you want to know that's not obtained from parse tree?

I need slightly more information and to do a little more testing to
describe the problem above in certanty. When I get to that point I'll
start another thread that's more meaningful.

Bob Rossi

Re: asynchronous MI output commands

[Vladimir Prus]

On Thursday 11 May 2006 06:37, Bob Rossi wrote:

> > > 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.

The "continue" command always produces

  *stopped

response and that's mostly enough for frontend.



>
> > 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.

What do you mean by "determine what an MI output command is"? You certainly 
can parse the response into DOM-like tree without knowing the output command.
If you want to create C data structures for each response, then yes, you'd 
need to know the exact type of the last command. But then, I'm not sure why 
you want to use C data structures. In KDevelop, the DOM is fully dynamic and 
that works just fine, for example:

    const GDBMI::Value& children = r["children"];

    for (unsigned i = 0; i < children.size(); ++i)
    {
        QString exp = children[i]["exp"].literal();


If you have specific structures for each response this won't be very much 
simpler.

> For asynchronous commands, there is simply no way to know what you are
> looking at AFAIK. 

What exactly do you want to know that's not obtained from parse tree?


- Volodya

 

Re: asynchronous MI output commands

[Bob Rossi]

> > 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.

> 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.

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.

Bob Rossi

RE: asynchronous MI output commands

[Alain Magloire]

> 
> Daniel Jacobowitz wrote:
> 
> > On Sun, May 07, 2006 at 11:09:51PM +0200, Bjarke Viksoe wrote:
> >> In my case I wish to submit several commands at once and slowly digest
> >> the answer (over a remote line where the network round-trip is slow).
> >> Using the <token> is clumsy and doesn't solve the problem of having
> >> enough information to process the answer without keeping track of the
> >> question. Since separate components handle the output autonomously, I
> had
> >> to give up tracking a command-list, and instead had to make sure only 1
> >> question was lingering - thus making the entire solution run much
> slower
> >> than otherwise needed.
> >>
> >> I found that commands that return "^value" result-records (such as
> >> -var-evaluate-expression and -data-evaluate-expression) doesn't carry
> >> enough information. I don't think a model where the entire command is
> >> repeated in the output is a desirable design, but at least identifying
> >> the question-type and its crucial parameters would suffice.
> >
> > If I were writing a front-end, I would have an arbitration layer which
> > sent questions to GDB and received answers.  The answers will come back
> > one at a time, in the same order the questions were asked.  If you send
> > two -var-evaluate-expression commands, you'll get back two answers, in
> > that same order.
> >
> > Am I missing something?  Is there a reason that this isn't enough?
> 
> 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").

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.

An implementation of MI could be made to be totally asynchronous if all
response could be tag to a matching command.  OOB should not be paired to
any commands. 

Re: asynchronous MI output commands

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Sun, May 07, 2006 at 11:09:51PM +0200, Bjarke Viksoe wrote:
>> In my case I wish to submit several commands at once and slowly digest
>> the answer (over a remote line where the network round-trip is slow).
>> Using the <token> is clumsy and doesn't solve the problem of having
>> enough information to process the answer without keeping track of the
>> question. Since separate components handle the output autonomously, I had
>> to give up tracking a command-list, and instead had to make sure only 1
>> question was lingering - thus making the entire solution run much slower
>> than otherwise needed.
>> 
>> I found that commands that return "^value" result-records (such as
>> -var-evaluate-expression and -data-evaluate-expression) doesn't carry
>> enough information. I don't think a model where the entire command is
>> repeated in the output is a desirable design, but at least identifying
>> the question-type and its crucial parameters would suffice.
> 
> If I were writing a front-end, I would have an arbitration layer which
> sent questions to GDB and received answers.  The answers will come back
> one at a time, in the same order the questions were asked.  If you send
> two -var-evaluate-expression commands, you'll get back two answers, in
> that same order.
> 
> Am I missing something?  Is there a reason that this isn't enough?

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.

- Volodya

Re: asynchronous MI output commands

[Bob Rossi]

On Sun, May 07, 2006 at 09:26:15PM -0400, Daniel Jacobowitz wrote:
> On Sun, May 07, 2006 at 08:29:35PM -0400, Bob Rossi wrote:
> > OK. I start with the MI output. I use bison to convert that into an
> > abstract parse tree. Now, I am working on a solution to take the
> > abstract parse tree and turn it into a simple to use representation for
> > the front end (ADT). I gave the example earlier, taking the abstract parse
> > tree for -file-list-exec-source-file 
> >   ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
> > and turn that into
> >   struct file_list_exec_source_file
> >   {
> >     int line;
> >     char *file;
> >     char *fullname;
> >   };
> >   struct file_list_exec_source_file result = { 26, "test.c", "/home..."};
> 
> [What's ADT mean then?  The "A" can't be abstract, there's nothing
> abstract about this.]

Oops, my terminology is off again. I'm sorry. I'll try to do better in
the future. I simply want to create a specific struct for each MI output
command. 

I'm making some progress on this task. I'm going to post what I've got
in a few days. I'm not happy with the way it's turning out, due to the
fact that the MI output commands don't describe what kind of output
command they are. However, with comments from you and Nick, I'm sure I
can work it out.

Thanks,
Bob Rossi

RE: asynchronous MI output commands

[Alain Magloire]

> Daniel Jacobowitz
> 
> On Sun, May 07, 2006 at 08:29:35PM -0400, Bob Rossi wrote:

....
> > Yes, I agree, if I knew the MI input command, I could use that to
> > determine what type of command I was looking at. If I won't be allowed
> > to add the command to the output record, then this is what I will do.
> >
> > However, I would like to be able to do this with out knowing the MI
> input
> > command. First, it makes the code more modular that takes the MI output
> > and turns it into something meaningful. Second, it's easy to gather a
> > bunch of MI output commands from the test suite or from FE user's with
> > FE problem, and parse just that output. Third, it validates that what
> > the user requested is what the user is getting. It is possible that the
> > FE and GDB could get mixed up I'm assumming.
> 
> You're trying to turn a response into a meaningful message without
> knowing what it's a response to.  I just don't see the benefit of this;
> although people keep telling me it's harder than I understand, I
> still haven't seen an example that I consider plausible.
> 

Right, 8-).  I think folks writing front-ends go naturally in that direction
because it is simply easier and it decouples the code so we do not need to
synchronize between commands and response.  Basically you can have one
thread posting commands and another parsing response.  But that said, I have
to agree with you, it is not a necessity and in reality we will need to
associate response with a command or a caller i.e. to update a tree view or
whatever viewer that initiate the sequence.

> It's easy to gather output from e.g. the testsuite, true.  But it's
> equally easy to record the commands - just about everything is going to
> go through mi_gdb_test, or you could even write a proxy between the
> testsuite and GDB which logged, or add the logging to GDB directly.  I
> know Eclipse's MI protocol log includes the commands it sent.
> 
> Your third point is valid, but does not seem particularly important to
> me.  If it's wrong, it's wrong.  GDB would just have to stitch the
> command name on at the end right before outputing the result record,
> so that wouldn't gain you much at all.
>

MI offers a simple way to associate response and commands, by tagging the
commands the ^done will come back with the associated tag.

> > Anyways, Daniel, thanks for taking time out of your busy schedule to
> > think about this issue. If you simply don't want something like this in
> > MI right now, I'll find a way to match the input with the output.
> 
> I'm not supreme dictator of this stuff; someone else is welcome to step
> in and disagree.  I'm just not convinced, either.
> 

OOB messages are important and are not necessarily associated with a
command, they may be side effects of something the front-end did not
initiate, for example loading libraries, creating threads etc ..

As you decoupling completely responses form command, may look like a good
idea only on the surface.

Re: asynchronous MI output commands

[Bob Rossi]

On Mon, May 08, 2006 at 01:52:08PM +1200, Nick Roberts wrote:
>  > Anyways, Daniel, thanks for taking time out of your busy schedule to
>  > think about this issue. If you simply don't want something like this in
>  > MI right now, I'll find a way to match the input with the output.
> 
> I must say that I agree with Daniel.  I think that by trying to classify the
> output as synchronous/asynchronous you're creating a problem, not solving one.

OK. Thanks Nick and Daniel! I'll work with what I've got for now. I
appreciate the effort and the resources you both put into this. If I run
into a wall, I'll let you know.

Bob Rossi

Re: asynchronous MI output commands

[Nick Roberts]

 > Anyways, Daniel, thanks for taking time out of your busy schedule to
 > think about this issue. If you simply don't want something like this in
 > MI right now, I'll find a way to match the input with the output.

I must say that I agree with Daniel.  I think that by trying to classify the
output as synchronous/asynchronous you're creating a problem, not solving one.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Sun, May 07, 2006 at 08:29:35PM -0400, Bob Rossi wrote:
> OK. I start with the MI output. I use bison to convert that into an
> abstract parse tree. Now, I am working on a solution to take the
> abstract parse tree and turn it into a simple to use representation for
> the front end (ADT). I gave the example earlier, taking the abstract parse
> tree for -file-list-exec-source-file 
>   ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
> and turn that into
>   struct file_list_exec_source_file
>   {
>     int line;
>     char *file;
>     char *fullname;
>   };
>   struct file_list_exec_source_file result = { 26, "test.c", "/home..."};

[What's ADT mean then?  The "A" can't be abstract, there's nothing
abstract about this.]

> > You don't
> > need to know what the data is to do that.  If you want to create
> > individual response structure types for each supported MI command, then
> > you ought to know what command is being answered (see my mail a moment
> > ago for why), and be able to convert the _abstract_ tree into an
> > appropriate _concrete_ structure.
> 
> Yes, I agree, if I knew the MI input command, I could use that to
> determine what type of command I was looking at. If I won't be allowed
> to add the command to the output record, then this is what I will do.
> 
> However, I would like to be able to do this with out knowing the MI input 
> command. First, it makes the code more modular that takes the MI output
> and turns it into something meaningful. Second, it's easy to gather a
> bunch of MI output commands from the test suite or from FE user's with
> FE problem, and parse just that output. Third, it validates that what
> the user requested is what the user is getting. It is possible that the
> FE and GDB could get mixed up I'm assumming.

You're trying to turn a response into a meaningful message without
knowing what it's a response to.  I just don't see the benefit of this;
although people keep telling me it's harder than I understand, I
still haven't seen an example that I consider plausible.

It's easy to gather output from e.g. the testsuite, true.  But it's
equally easy to record the commands - just about everything is going to
go through mi_gdb_test, or you could even write a proxy between the
testsuite and GDB which logged, or add the logging to GDB directly.  I
know Eclipse's MI protocol log includes the commands it sent.

Your third point is valid, but does not seem particularly important to
me.  If it's wrong, it's wrong.  GDB would just have to stitch the
command name on at the end right before outputing the result record,
so that wouldn't gain you much at all.

> Anyways, Daniel, thanks for taking time out of your busy schedule to
> think about this issue. If you simply don't want something like this in
> MI right now, I'll find a way to match the input with the output.

I'm not supreme dictator of this stuff; someone else is welcome to step
in and disagree.  I'm just not convinced, either.

-- 
Daniel Jacobowitz
CodeSourcery

Re: asynchronous MI output commands

[Bob Rossi]

On Sun, May 07, 2006 at 05:27:11PM -0400, Daniel Jacobowitz wrote:
> On Sat, May 06, 2006 at 08:45:18PM -0400, Bob Rossi wrote:
> > OK, with that information, I see it is impossible to tell just from 
> > looking at the MI output, to determine if the command is synchronous 
> > or not. Look below for a solution to this problem for me.
> 
> What?  ^done is a synchronous response, *stopped is an asynchronous
> response.  There's not really any way of knowing whether a command
> might produce later asynchronous output.
> 
> [Here we run into the limits of the current, mostly synchronous
> implementation.]

Daniel, 

Please also notice that Xcode actually did modify the MI protocol to
tell the front end about the asynchronous commands.

http://sourceware.org/ml/gdb/2004-09/msg00238.html

Bob Rossi

Re: asynchronous MI output commands

[Bob Rossi]

> > Hmmm. That's interesting, I was hoping to not need to know what the
> > input command was in order to parse and build an ADT for the output. In
> > general, I think it would be appropriate if the MI output described
> > itself well enough that no other information was needed to understand
> > it, including the MI intput command.
> 
> What do you mean, in this context, by an ADT (and what does it mean to
> you)?  And what information do you want to represent in your parse
> result?  I think I need to understand what you want to get out of this
> data a little better.

OK. I start with the MI output. I use bison to convert that into an
abstract parse tree. Now, I am working on a solution to take the
abstract parse tree and turn it into a simple to use representation for
the front end (ADT). I gave the example earlier, taking the abstract parse
tree for -file-list-exec-source-file 
  ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
and turn that into
  struct file_list_exec_source_file
  {
    int line;
    char *file;
    char *fullname;
  };
  struct file_list_exec_source_file result = { 26, "test.c", "/home..."};
  
My goal is to do this for each MI output command. I would also like to
make sure the manual reflects all the current MI commands, with the
appropriate fields, and at the end, generate the documentation from this
simple program (with ELI's help). BTW, this is all before I even try to
implement the MI implementation into my front end, so that others can
benefit from this work. Having a LISP or XML output from this program
would be trivial and I'm sure would help others down the road.

> It seems to me that most of the work of an MI parser is in converting
> the RESULT rule to some more useful tree-like structure.  

Yes, this is already done.

> You don't
> need to know what the data is to do that.  If you want to create
> individual response structure types for each supported MI command, then
> you ought to know what command is being answered (see my mail a moment
> ago for why), and be able to convert the _abstract_ tree into an
> appropriate _concrete_ structure.

Yes, I agree, if I knew the MI input command, I could use that to
determine what type of command I was looking at. If I won't be allowed
to add the command to the output record, then this is what I will do.

However, I would like to be able to do this with out knowing the MI input 
command. First, it makes the code more modular that takes the MI output
and turns it into something meaningful. Second, it's easy to gather a
bunch of MI output commands from the test suite or from FE user's with
FE problem, and parse just that output. Third, it validates that what
the user requested is what the user is getting. It is possible that the
FE and GDB could get mixed up I'm assumming.

Anyways, Daniel, thanks for taking time out of your busy schedule to
think about this issue. If you simply don't want something like this in
MI right now, I'll find a way to match the input with the output.

Bob Rossi

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Sat, May 06, 2006 at 08:45:18PM -0400, Bob Rossi wrote:
> OK, with that information, I see it is impossible to tell just from 
> looking at the MI output, to determine if the command is synchronous 
> or not. Look below for a solution to this problem for me.

What?  ^done is a synchronous response, *stopped is an asynchronous
response.  There's not really any way of knowing whether a command
might produce later asynchronous output.

[Here we run into the limits of the current, mostly synchronous
implementation.]

> Hmmm. That's interesting, I was hoping to not need to know what the
> input command was in order to parse and build an ADT for the output. In
> general, I think it would be appropriate if the MI output described
> itself well enough that no other information was needed to understand
> it, including the MI intput command.

What do you mean, in this context, by an ADT (and what does it mean to
you)?  And what information do you want to represent in your parse
result?  I think I need to understand what you want to get out of this
data a little better.

It seems to me that most of the work of an MI parser is in converting
the RESULT rule to some more useful tree-like structure.  You don't
need to know what the data is to do that.  If you want to create
individual response structure types for each supported MI command, then
you ought to know what command is being answered (see my mail a moment
ago for why), and be able to convert the _abstract_ tree into an
appropriate _concrete_ structure.

-- 
Daniel Jacobowitz
CodeSourcery

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Sun, May 07, 2006 at 11:09:51PM +0200, Bjarke Viksoe wrote:
> In my case I wish to submit several commands at once and slowly digest the 
> answer (over a remote line where the network round-trip is slow). Using the 
> <token> is clumsy and doesn't solve the problem of having enough 
> information to process the answer without keeping track of the question. 
> Since separate components handle the output autonomously, I had to give up 
> tracking a command-list, and instead had to make sure only 1 question was 
> lingering - thus making the entire solution run much slower than otherwise 
> needed.
> 
> I found that commands that return "^value" result-records (such as 
> -var-evaluate-expression and -data-evaluate-expression) doesn't carry 
> enough information. I don't think a model where the entire command is 
> repeated in the output is a desirable design, but at least identifying the 
> question-type and its crucial parameters would suffice.

If I were writing a front-end, I would have an arbitration layer which
sent questions to GDB and received answers.  The answers will come back
one at a time, in the same order the questions were asked.  If you send
two -var-evaluate-expression commands, you'll get back two answers, in
that same order.

Am I missing something?  Is there a reason that this isn't enough?

-- 
Daniel Jacobowitz
CodeSourcery

Re: asynchronous MI output commands

[Bjarke Viksoe]

>From: Bob Rossi >
> > You can easily categorize a ^done or ^error response as synchronous.
> > Other responses are more difficult to associate with a command, because
> > they weren't directly issued as the response to a command.
> >
> > > It could output
> > >
> > > -file-list-exec-source-file
> > > %-file-list-exec-source-file
> > > 
>^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
> > > (gdb)
> >
> > Accomplishing what?  This is synchronous.  It's a response to the
> > previously issued command.  The front end knows exactly what its
> > previously issued command was, I hope.
>
>Hmmm. That's interesting, I was hoping to not need to know what the
>input command was in order to parse and build an ADT for the output. In
>general, I think it would be appropriate if the MI output described
>itself well enough that no other information was needed to understand
>it, including the MI intput command.
>
>...
>
>Thanks,
>Bob Rossi

When I started using the MI a long time ago I assumed the same - that the MI 
output would define to some extent what was asked.
This would make the front-end much more state-less and easy to do.
Unfortunately it does not appear to be the case. I think the general 
suggestion is to make use of the <token> part of the command syntax to allow 
you to match the answer with the question - leaving it up to you to keep 
track of input-parameters, commands and context.

In my case I wish to submit several commands at once and slowly digest the 
answer (over a remote line where the network round-trip is slow). Using the 
<token> is clumsy and doesn't solve the problem of having enough information 
to process the answer without keeping track of the question. Since separate 
components handle the output autonomously, I had to give up tracking a 
command-list, and instead had to make sure only 1 question was lingering - 
thus making the entire solution run much slower than otherwise needed.

I found that commands that return "^value" result-records (such as 
-var-evaluate-expression and -data-evaluate-expression) doesn't carry enough 
information. I don't think a model where the entire command is repeated in 
the output is a desirable design, but at least identifying the question-type 
and its crucial parameters would suffice.

regards
bjarke

Re: asynchronous MI output commands

[Bob Rossi]

> > I was hoping to tell the front end if the command was asynchronous or
> > not. There is a use in knowing if the command is asynchronous or not.
> > First of, if the command is asynchronous then I don't have to probe the
> > parse tree to determine if it represents the results to say,
> > -file-list-exec-source-file or some other commands. I know when building
> > the ADT for the FE that it's an asynchronous command, and that limits
> > the amount of probing in the parse tree I have to do.
> 
> That's not the difference between synchronous and asynchronous, in MI:
> think of it instead as the difference between synchronous and
> everything else.  A synchronous response from MI corresponds to a
> front-end command.  Everything else corresponds to other state changes,
> which may be related to some command or not, in a less than obvious
> way.

OK, with that information, I see it is impossible to tell just from 
looking at the MI output, to determine if the command is synchronous 
or not. Look below for a solution to this problem for me.

> You can easily categorize a ^done or ^error response as synchronous.
> Other responses are more difficult to associate with a command, because
> they weren't directly issued as the response to a command.
> 
> > It could output
> > 
> > -file-list-exec-source-file
> > %-file-list-exec-source-file
> > ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
> > (gdb)
> 
> Accomplishing what?  This is synchronous.  It's a response to the
> previously issued command.  The front end knows exactly what its
> previously issued command was, I hope.

Hmmm. That's interesting, I was hoping to not need to know what the
input command was in order to parse and build an ADT for the output. In
general, I think it would be appropriate if the MI output described
itself well enough that no other information was needed to understand
it, including the MI intput command.

I think I could accomplish this task, as well as understand what is
synchronous and asynchronous by adding a little bit of output to each
synchronous command like shown above. Showing the MI command that GDB 
is responding to in the MI output would do just the trick. Would a
simple patch that changed the output like this be welcome?

from
    result-record ==>
	[ token ] "^" result-class ( "," result )* nl
to something like

    result-record ==>
	[ token ] mi-input-command "^" result-class ( "," result )* nl

The above is just a simple suggestion to show the goal. I'm not sure if
that would be the best place to change the code. I'd like to do it in a
way that didn't break the MI output syntax.

Thanks,
Bob Rossi

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Sat, May 06, 2006 at 03:46:18PM -0400, Bob Rossi wrote:
> OK, we are going in circles. I currently have a goal of determining if a
> MI output is synchronous or asynchronous.

So you keep saying - but I'm not sure that you're asking the right
question.

> > I still don't understand the question - the point of categorizing
> > messages in this way.
> 
> I was hoping to tell the front end if the command was asynchronous or
> not. There is a use in knowing if the command is asynchronous or not.
> First of, if the command is asynchronous then I don't have to probe the
> parse tree to determine if it represents the results to say,
> -file-list-exec-source-file or some other commands. I know when building
> the ADT for the FE that it's an asynchronous command, and that limits
> the amount of probing in the parse tree I have to do.

That's not the difference between synchronous and asynchronous, in MI:
think of it instead as the difference between synchronous and
everything else.  A synchronous response from MI corresponds to a
front-end command.  Everything else corresponds to other state changes,
which may be related to some command or not, in a less than obvious
way.

You can easily categorize a ^done or ^error response as synchronous.
Other responses are more difficult to associate with a command, because
they weren't directly issued as the response to a command.

> It could output
> 
> -file-list-exec-source-file
> %-file-list-exec-source-file
> ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
> (gdb)

Accomplishing what?  This is synchronous.  It's a response to the
previously issued command.  The front end knows exactly what its
previously issued command was, I hope.

-- 
Daniel Jacobowitz
CodeSourcery

Re: asynchronous MI output commands

[Bob Rossi]

On Sat, May 06, 2006 at 12:52:49PM -0400, Daniel Jacobowitz wrote:
> On Sat, May 06, 2006 at 12:40:31PM -0400, Bob Rossi wrote:
> > Each of the lines beggining with ~ are an 
> >   out-of-band-record => stream-record.
> > There is no out-of-band-record => async-record.
> > 
> > Certainly having an out-of-band-record => stream-record does not make an
> > MI output command asynchronous. Or does it?
> 
> `OUTPUT ==>'
>      `( OUT-OF-BAND-RECORD )* [ RESULT-RECORD ] "(gdb)" NL'
> 
> It's an OOB record, followed by a prompt.  It's not the direct output of
> any command.

OK, we are going in circles. I currently have a goal of determining if a
MI output is synchronous or asynchronous. So far, I think we have agreed
that an asynchronous command from GDB is a command that is sent from GDB
that was not a response from a command sent to GDB from the FE.

GDB uses the term asynchronous all over the place in the manual, even if
the asynchronous part is faked. I was under the impression that every 
asynchronous MI output command would have to funnel through the
  'async-record ==>' part of the grammar. You mentioned I could look for
*stopped, which is down stream of async-record.

So, either this is a special case, or we could put into this case the
reason GDB is sending data to the front end, which I think would be
appropriate. In fact something like,

~"GNU gdb 6.1-debian\n"
~"Copyright 2004 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\n"
~"welcome to change it and/or distribute copies of it under certain conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
~"This GDB was configured as \"i386-linux\"..."
~"Using host libthread_db library \"/lib/libthread_db.so.1\".\n"
~"\n"
*stream-update
(gdb)

and change

async-class ==>
    "stopped" | others (where others will be added depending on the needs--this is still in development).

to

async-class ==>
    "stopped" | "stream-update" | others ...

I know this seems rather pedantic, and I'm not trying to cause problems
where there are none, however, this case just doesn't make sense. Of
course I could just consider it synchronous and everything will just
work fine, however, I'd like to make this as pure as possible.
  
> > The code I wrote to determine if an MI output command is asynchronous
> > checks to see if there is an out-of-band-record=>async-record in the
> > parse tree. If there is, the command is asynchronous, otherwise it's
> > not. Do you disagree with this?
> 
> "MI output command" doesn't mean anything to me.  It's an MI output
> record, and it isn't in response to a command.

Sorry, I was using the term "MI output command" to mean a single
response from GDB to the FE. In the grammar that would be 'output ==>'.

> I still don't understand the question - the point of categorizing
> messages in this way.

I was hoping to tell the front end if the command was asynchronous or
not. There is a use in knowing if the command is asynchronous or not.
First of, if the command is asynchronous then I don't have to probe the
parse tree to determine if it represents the results to say,
-file-list-exec-source-file or some other commands. I know when building
the ADT for the FE that it's an asynchronous command, and that limits
the amount of probing in the parse tree I have to do.

Ideally, I wouldn't have to prove at all, GDB should probably state in
the MI output what kind of command it's responding to. For instance, 
instead of

-file-list-exec-source-file
^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
(gdb)

It could output

-file-list-exec-source-file
%-file-list-exec-source-file
^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
(gdb)

Anyways, I'm going over board for now, but I hope you can see the reason I'm
asking for this functionality in the initial response from GDB.

Thanks,
Bob Rossi

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Sat, May 06, 2006 at 12:40:31PM -0400, Bob Rossi wrote:
> Each of the lines beggining with ~ are an 
>   out-of-band-record => stream-record.
> There is no out-of-band-record => async-record.
> 
> Certainly having an out-of-band-record => stream-record does not make an
> MI output command asynchronous. Or does it?

`OUTPUT ==>'
     `( OUT-OF-BAND-RECORD )* [ RESULT-RECORD ] "(gdb)" NL'

It's an OOB record, followed by a prompt.  It's not the direct output of
any command.

> The code I wrote to determine if an MI output command is asynchronous
> checks to see if there is an out-of-band-record=>async-record in the
> parse tree. If there is, the command is asynchronous, otherwise it's
> not. Do you disagree with this?

"MI output command" doesn't mean anything to me.  It's an MI output
record, and it isn't in response to a command.

I still don't understand the question - the point of categorizing
messages in this way.

-- 
Daniel Jacobowitz
CodeSourcery

Re: asynchronous MI output commands

[Bob Rossi]

On Sat, May 06, 2006 at 11:20:46AM -0400, Daniel Jacobowitz wrote:
> On Sat, May 06, 2006 at 07:49:34AM -0400, Bob Rossi wrote:
> > Right, synchronous is a response to a command. That's also the
> > definition I was using. However the initial output is not a response to
> > a command and it also does not semantically end up being asynchronous.
> 
> Why do you think it is not asynchronous?  If you want to be picky about
> the grammar, it's an out of band message.

~"GNU gdb 6.1-debian\n"
~"Copyright 2004 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\n"
~"welcome to change it and/or distribute copies of it under certain conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
~"This GDB was configured as \"i386-linux\"..."
~"Using host libthread_db library \"/lib/libthread_db.so.1\".\n"
~"\n"
(gdb)

Each of the lines beggining with ~ are an 
  out-of-band-record => stream-record.
There is no out-of-band-record => async-record.

Certainly having an out-of-band-record => stream-record does not make an
MI output command asynchronous. Or does it?

The code I wrote to determine if an MI output command is asynchronous
checks to see if there is an out-of-band-record=>async-record in the
parse tree. If there is, the command is asynchronous, otherwise it's
not. Do you disagree with this?

Thanks,
Bob Rossi

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Sat, May 06, 2006 at 07:49:34AM -0400, Bob Rossi wrote:
> Right, synchronous is a response to a command. That's also the
> definition I was using. However the initial output is not a response to
> a command and it also does not semantically end up being asynchronous.

Why do you think it is not asynchronous?  If you want to be picky about
the grammar, it's an out of band message.

-- 
Daniel Jacobowitz
CodeSourcery

Re: asynchronous MI output commands

[Bob Rossi]

On Sat, May 06, 2006 at 03:27:05PM +1200, Nick Roberts wrote:
>  > Starting with this MI output command, 
>  >   -file-list-exec-source-file
>  >   ^done,line="1",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c"
>  >   (gdb)
>  > I get back a parse tree, and from that, I'll define something like,
>  > 
>  > struct file_list_exec_source_file
>  > {
>  >   int line;
>  >   char *filename;
>  >   char *fullname;
>  > };
>  > 
>  > with the correct values filled in.
>  
> Presumably Emacs would need the parser to output Lisp.

Sounds great to me.

>  > So far, I've created the parse tree code, and a small TCL extension
>  > which allows me to grab all of the MI output commands from the
>  > testsuite. I've written all of these output commands to a temporary file,
>  > which I use for input to my drive program.
> 
> Emacs has a Lisp interpreter, of course, so it could take Lisp output from a
> parser and act on it.  AFAIK C isn't interpreted, so how does your program use
> it?

I probably wasn't clear here. I have the MI parser, which just creates
the parse tree. I wrote a small TCL extension that is capable of taking
an MI output command and writing it to a file if the parse passed.

            set parse_result [gdbmi_parse $expect_out(2,string)]
            if [string match "syntax error" $parse_result] then {
              puts "MI_OUTPUT_COMMAND($expect_out(2,string))"
              fail "Syntax check of MI Output Command failed"
            } else {
               puts -nonewline $fileId $expect_out(2,string)
            }
So, after I run the testsuite, I have all the valid MI output commands
from the test suite in /tmp/data.mi.

Then, I have a driver program which reads a file that has MI
descriptions in it (/tmp/data.mi) and parses each of them. I am know
starting to work on the part that takes the parse tree and provides a
semantically correct data structure for the front end to use. The only
reason I wrote the tcl extension is to validate the test suite. It
turned out I was also easily able to gather a bunch of MI output
commands for testing as well.

>  > My question is, should we say it's a bug on GDB's part if reason= isn't
>  > the first pair returned for an asynchronous MI output command? Should I
>  > assume if the MI output command has reason= anywhere in it that it's an
>  > asynchronous command? or should we add an extra piece of information into 
>  > the MI output command stating that the command is asynchronous. 
>  > For instance,
>  > 
>  >   47*stopped,asynchronous,reason="end-stepping-range",thread-id="0", ...
> 
> I think you should assume that if it has *stopped, the output is asynchronous.
> Of course, as we've said before, currently all the output (except possibly for
> a remote target) is synchronous in reality.

OK, I will take your suggestion, as well as Daniel's on this point.
Thanks for the help.

Bob Rossi

Re: asynchronous MI output commands

[Bob Rossi]

On Sat, May 06, 2006 at 03:36:53PM +1200, Nick Roberts wrote:
>  > I just happened to notice that -exec-next and -interpreter-exec console
>  > next are surprisingly different.
>  > 
>  > (gdb)
>  > -exec-next
>  > ^running (gdb)
>  > *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x0804836b",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbf80e254"}],file="main.c",line="5"}
>  > (gdb)
>  > -interpreter-exec console next
>  > ~"6\t  return 0;\n"
>  > ^done
>  > (gdb)
> 
> The branch that I want to create, when I have proper internet access, will
> give asynchronous output (*stopped) for both commands.

Wow Nick, that would be great. At some point in the near future I might
have time to help out with this if you need it. Let me know.

>  > Is next asynchronuos in 1 case and not the other?
> 
> They're both synchronous at the moment (the "*stopped" for -exec-next is faked).

Yeah, I do remember this from last year. I would love to see them become
asynchronous. That might be something I work on for mi3 if you don't
beat me to it :)

> Bob, I would guess that MI output is likely to continue to change so I would
> try to factor that into your parser.

Thanks for the advice! In a few weeks I'll probably have some reasonable
ground work done on the parser, I'll post a link if anyone's interested.

Bob Rossi

Re: asynchronous MI output commands

[Bob Rossi]

On Sat, May 06, 2006 at 12:05:53AM -0400, Daniel Jacobowitz wrote:
> On Fri, May 05, 2006 at 10:49:02PM -0400, Bob Rossi wrote:
> > OK, I could do this, and if that's the prefered way, then I will. The
> > only strange thing about it, is either I need to hack up the parser to
> > set a flag when it reaches that point, or I need to walk the parse tree
> > semi-deep to get that info. Do you still think that would be the
> > prefered way? Actually, I could just see if I ever get to the
> > async-record to determine if the command is asynchronous, right?
> 
> I just don't understand what your goals and terms are here.

I guess I don't either, I'm just trying to understand how to look at
each MI output command and how to classify them.

> The MI output syntax has a grammar, and the grammar has semantic
> information.  One part of the grammar identifies what is synchronous
> and what is asynchronous.  If your parser can't keep track of that
> information, then perhaps you should think a little more about what
> information you need from parsing - that's pretty much the point of
> having a parser.

I aggree with you know, just needed someone else's point of view. I'll
check the parser to see if it went down the asynchronous route. Thanks.

Bob Rossi

Re: asynchronous MI output commands

[Bob Rossi]

On Sat, May 06, 2006 at 12:05:53AM -0400, Daniel Jacobowitz wrote:
> On Fri, May 05, 2006 at 10:49:02PM -0400, Bob Rossi wrote:
> > OK, I could do this, and if that's the prefered way, then I will. The
> > only strange thing about it, is either I need to hack up the parser to
> > set a flag when it reaches that point, or I need to walk the parse tree
> > semi-deep to get that info. Do you still think that would be the
> > prefered way? Actually, I could just see if I ever get to the
> > async-record to determine if the command is asynchronous, right?
> 
> I just don't understand what your goals and terms are here.

I guess I don't either, I'm just trying to understand how to look at
each MI output command and how to classify them.

> The MI output syntax has a grammar, and the grammar has semantic
> information.  One part of the grammar identifies what is synchronous
> and what is asynchronous.  If your parser can't keep track of that
> information, then perhaps you should think a little more about what
> information you need from parsing - that's pretty much the point of
> having a parser.

I aggree with you know, just needed someone else's point of view. I'll
check the parser to see if it went down the asynchronous route. Thanks.

Bob Rossi

Re: asynchronous MI output commands

[Bob Rossi]

On Sat, May 06, 2006 at 04:03:18PM +1200, Nick Roberts wrote:
>  > ~"GNU gdb 6.1-debian\n"
>  > ~"Copyright 2004 Free Software Foundation, Inc.\n"
>  > ~"GDB is free software, covered by the GNU General Public License, and you are\n"
>  > ~"welcome to change it and/or distribute copies of it under certain conditions.\n"
>  > ~"Type \"show copying\" to see the conditions.\n"
>  > ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
>  > ~"This GDB was configured as \"i386-linux\"..."
>  > ~"Using host libthread_db library \"/lib/libthread_db.so.1\".\n"
>  > ~"\n"
>  > (gdb)
>  > 
>  > Is this considered synchronous or asynchronous? I consider it
>  > asynchronous, and I don't have any way to tell that except check to see
>  > if the parse tree has nothing but stream messages. What do you think?
> 
> Can't you just consider it as output?  What would your parser do differently
> if it was classed as one or other?

It would do nothing differently. However, this is an asynchronous
command that appears to be synchronous. I think it's a bug in GDB. I
could be wrong.

Bob Rossi

Re: asynchronous MI output commands

[Bob Rossi]

On Sat, May 06, 2006 at 12:06:37AM -0400, Daniel Jacobowitz wrote:
> On Sat, May 06, 2006 at 04:03:18PM +1200, Nick Roberts wrote:
> > Can't you just consider it as output?  What would your parser do differently
> > if it was classed as one or other?
> > 
> > I think making the output asynchronous just determines how the front end can
> > interact with GDB, not its content.
> 
> Correct.  I think that "asynchronous" is a loaded term; it has too many
> meanings, most of which don't apply here.  Synchronous output is the
> response to a command.

Right, synchronous is a response to a command. That's also the
definition I was using. However the initial output is not a response to
a command and it also does not semantically end up being asynchronous.

I think this case doesn't make any sense. It should probably be
something like, 

$ gdb -i=mi
~"GNU gdb 6.3-debian\n"
~"Copyright 2004 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\n"
~"welcome to change it and/or distribute copies of it under certain conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
~"This GDB was configured as \"i486-linux-gnu\"."
~"\n"
*db-started
(gdb)

Are there any other cases like this? If not, do you mind if I make this
change?

BTW, I'm not trying to rock the boat here, I'm just trying to understand
how to classify each MI output command that I'm looking at.

Thanks,
Bob Rossi

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Sat, May 06, 2006 at 04:03:18PM +1200, Nick Roberts wrote:
> Can't you just consider it as output?  What would your parser do differently
> if it was classed as one or other?
> 
> I think making the output asynchronous just determines how the front end can
> interact with GDB, not its content.

Correct.  I think that "asynchronous" is a loaded term; it has too many
meanings, most of which don't apply here.  Synchronous output is the
response to a command.

-- 
Daniel Jacobowitz
CodeSourcery

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Fri, May 05, 2006 at 10:49:02PM -0400, Bob Rossi wrote:
> OK, I could do this, and if that's the prefered way, then I will. The
> only strange thing about it, is either I need to hack up the parser to
> set a flag when it reaches that point, or I need to walk the parse tree
> semi-deep to get that info. Do you still think that would be the
> prefered way? Actually, I could just see if I ever get to the
> async-record to determine if the command is asynchronous, right?

I just don't understand what your goals and terms are here.

The MI output syntax has a grammar, and the grammar has semantic
information.  One part of the grammar identifies what is synchronous
and what is asynchronous.  If your parser can't keep track of that
information, then perhaps you should think a little more about what
information you need from parsing - that's pretty much the point of
having a parser.

> I just happened to notice that -exec-next and -interpreter-exec console
> next are surprisingly different.

-interpreter-exec, essentially, is synchronous.  This is subject to
change.  The interaction between multiple interpreters is very
difficult.

-- 
Daniel Jacobowitz
CodeSourcery

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Fri, May 05, 2006 at 10:49:02PM -0400, Bob Rossi wrote:
> OK, I could do this, and if that's the prefered way, then I will. The
> only strange thing about it, is either I need to hack up the parser to
> set a flag when it reaches that point, or I need to walk the parse tree
> semi-deep to get that info. Do you still think that would be the
> prefered way? Actually, I could just see if I ever get to the
> async-record to determine if the command is asynchronous, right?

I just don't understand what your goals and terms are here.

The MI output syntax has a grammar, and the grammar has semantic
information.  One part of the grammar identifies what is synchronous
and what is asynchronous.  If your parser can't keep track of that
information, then perhaps you should think a little more about what
information you need from parsing - that's pretty much the point of
having a parser.

> I just happened to notice that -exec-next and -interpreter-exec console
> next are surprisingly different.

-interpreter-exec, essentially, is synchronous.  This is subject to
change.  The interaction between multiple interpreters is very
difficult.

-- 
Daniel Jacobowitz
CodeSourcery

Re: asynchronous MI output commands

[Nick Roberts]

 > ~"GNU gdb 6.1-debian\n"
 > ~"Copyright 2004 Free Software Foundation, Inc.\n"
 > ~"GDB is free software, covered by the GNU General Public License, and you are\n"
 > ~"welcome to change it and/or distribute copies of it under certain conditions.\n"
 > ~"Type \"show copying\" to see the conditions.\n"
 > ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
 > ~"This GDB was configured as \"i386-linux\"..."
 > ~"Using host libthread_db library \"/lib/libthread_db.so.1\".\n"
 > ~"\n"
 > (gdb)
 > 
 > Is this considered synchronous or asynchronous? I consider it
 > asynchronous, and I don't have any way to tell that except check to see
 > if the parse tree has nothing but stream messages. What do you think?

Can't you just consider it as output?  What would your parser do differently
if it was classed as one or other?

I think making the output asynchronous just determines how the front end can
interact with GDB, not its content.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: asynchronous MI output commands

[Nick Roberts]

 > I just happened to notice that -exec-next and -interpreter-exec console
 > next are surprisingly different.
 > 
 > (gdb)
 > -exec-next
 > ^running (gdb)
 > *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x0804836b",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbf80e254"}],file="main.c",line="5"}
 > (gdb)
 > -interpreter-exec console next
 > ~"6\t  return 0;\n"
 > ^done
 > (gdb)

The branch that I want to create, when I have proper internet access, will
give asynchronous output (*stopped) for both commands.

 > Is next asynchronuos in 1 case and not the other?

They're both synchronous at the moment (the "*stopped" for -exec-next is faked).

Bob, I would guess that MI output is likely to continue to change so I would
try to factor that into your parser.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

asynchronous MI output commands

[Nick Roberts]

 > Starting with this MI output command, 
 >   -file-list-exec-source-file
 >   ^done,line="1",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c"
 >   (gdb)
 > I get back a parse tree, and from that, I'll define something like,
 > 
 > struct file_list_exec_source_file
 > {
 >   int line;
 >   char *filename;
 >   char *fullname;
 > };
 > 
 > with the correct values filled in.
 
Presumably Emacs would need the parser to output Lisp.

 > So far, I've created the parse tree code, and a small TCL extension
 > which allows me to grab all of the MI output commands from the
 > testsuite. I've written all of these output commands to a temporary file,
 > which I use for input to my drive program.

Emacs has a Lisp interpreter, of course, so it could take Lisp output from a
parser and act on it.  AFAIK C isn't interpreted, so how does your program use
it?

 > My question is, should we say it's a bug on GDB's part if reason= isn't
 > the first pair returned for an asynchronous MI output command? Should I
 > assume if the MI output command has reason= anywhere in it that it's an
 > asynchronous command? or should we add an extra piece of information into 
 > the MI output command stating that the command is asynchronous. 
 > For instance,
 > 
 >   47*stopped,asynchronous,reason="end-stepping-range",thread-id="0", ...

I think you should assume that if it has *stopped, the output is asynchronous.
Of course, as we've said before, currently all the output (except possibly for
a remote target) is synchronous in reality.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: asynchronous MI output commands

[Bob Rossi]

On Fri, May 05, 2006 at 09:59:03PM -0400, Daniel Jacobowitz wrote:
> On Fri, May 05, 2006 at 09:27:06PM -0400, Bob Rossi wrote:
> > The first problem that I've run into is determining if an MI output
> > command is synchronous or asynchronous. I can tell if the MI output
> > command is asynchronous by looking for, reason="abc", like below,
> >   47*stopped,reason="end-stepping-range",thread-id="0", ...
> 
> `ASYNC-RECORD ==>'
>      `EXEC-ASYNC-OUTPUT | STATUS-ASYNC-OUTPUT | NOTIFY-ASYNC-OUTPUT'
> 
> `EXEC-ASYNC-OUTPUT ==>'
>      `[ TOKEN ] "*" ASYNC-OUTPUT'
> 
> `STATUS-ASYNC-OUTPUT ==>'
>      `[ TOKEN ] "+" ASYNC-OUTPUT'
> 
> `NOTIFY-ASYNC-OUTPUT ==>'
>      `[ TOKEN ] "=" ASYNC-OUTPUT'
> 
> Why can't you tell that output is asynchronous from the *stopped, as
> opposed to ^done?

Also, what about this case?

~"GNU gdb 6.1-debian\n"
~"Copyright 2004 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\n"
~"welcome to change it and/or distribute copies of it under certain conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
~"This GDB was configured as \"i386-linux\"..."
~"Using host libthread_db library \"/lib/libthread_db.so.1\".\n"
~"\n"
(gdb)

Is this considered synchronous or asynchronous? I consider it
asynchronous, and I don't have any way to tell that except check to see
if the parse tree has nothing but stream messages. What do you think?

Thanks,
Bob Rossi

Re: asynchronous MI output commands

[Bob Rossi]

On Fri, May 05, 2006 at 09:59:03PM -0400, Daniel Jacobowitz wrote:
> On Fri, May 05, 2006 at 09:27:06PM -0400, Bob Rossi wrote:
> > The first problem that I've run into is determining if an MI output
> > command is synchronous or asynchronous. I can tell if the MI output
> > command is asynchronous by looking for, reason="abc", like below,
> >   47*stopped,reason="end-stepping-range",thread-id="0", ...
> 
> `ASYNC-RECORD ==>'
>      `EXEC-ASYNC-OUTPUT | STATUS-ASYNC-OUTPUT | NOTIFY-ASYNC-OUTPUT'
> 
> `EXEC-ASYNC-OUTPUT ==>'
>      `[ TOKEN ] "*" ASYNC-OUTPUT'
> 
> `STATUS-ASYNC-OUTPUT ==>'
>      `[ TOKEN ] "+" ASYNC-OUTPUT'
> 
> `NOTIFY-ASYNC-OUTPUT ==>'
>      `[ TOKEN ] "=" ASYNC-OUTPUT'
> 
> Why can't you tell that output is asynchronous from the *stopped, as
> opposed to ^done?

OK, I could do this, and if that's the prefered way, then I will. The
only strange thing about it, is either I need to hack up the parser to
set a flag when it reaches that point, or I need to walk the parse tree
semi-deep to get that info. Do you still think that would be the
prefered way? Actually, I could just see if I ever get to the
async-record to determine if the command is asynchronous, right?

I just happened to notice that -exec-next and -interpreter-exec console
next are surprisingly different.

(gdb)
-exec-next
^running (gdb)
*stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x0804836b",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbf80e254"}],file="main.c",line="5"}
(gdb)
-interpreter-exec console next
~"6\t  return 0;\n"
^done
(gdb)

Is next asynchronuos in 1 case and not the other?

Bob Rossi

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Fri, May 05, 2006 at 09:27:06PM -0400, Bob Rossi wrote:
> The first problem that I've run into is determining if an MI output
> command is synchronous or asynchronous. I can tell if the MI output
> command is asynchronous by looking for, reason="abc", like below,
>   47*stopped,reason="end-stepping-range",thread-id="0", ...

`ASYNC-RECORD ==>'
     `EXEC-ASYNC-OUTPUT | STATUS-ASYNC-OUTPUT | NOTIFY-ASYNC-OUTPUT'

`EXEC-ASYNC-OUTPUT ==>'
     `[ TOKEN ] "*" ASYNC-OUTPUT'

`STATUS-ASYNC-OUTPUT ==>'
     `[ TOKEN ] "+" ASYNC-OUTPUT'

`NOTIFY-ASYNC-OUTPUT ==>'
     `[ TOKEN ] "=" ASYNC-OUTPUT'

Why can't you tell that output is asynchronous from the *stopped, as
opposed to ^done?

-- 
Daniel Jacobowitz
CodeSourcery

asynchronous MI output commands

[Bob Rossi]

Hi,

I'm finally getting more time to build the next layer on top of my MI
parser. This layer will look at the parse tree and create a data
structure from it that the front end will find more useful. For
instance, for example,

Starting with this MI output command, 
  -file-list-exec-source-file
  ^done,line="1",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c"
  (gdb)
I get back a parse tree, and from that, I'll define something like,

struct file_list_exec_source_file
{
  int line;
  char *filename;
  char *fullname;
};

with the correct values filled in.


So far, I've created the parse tree code, and a small TCL extension
which allows me to grab all of the MI output commands from the
testsuite. I've written all of these output commands to a temporary file,
which I use for input to my drive program.

The first problem that I've run into is determining if an MI output
command is synchronous or asynchronous. I can tell if the MI output
command is asynchronous by looking for, reason="abc", like below,
  47*stopped,reason="end-stepping-range",thread-id="0", ...

I'm assuming reason= has to be the first pair after stopped, or done,.

My question is, should we say it's a bug on GDB's part if reason= isn't
the first pair returned for an asynchronous MI output command? Should I
assume if the MI output command has reason= anywhere in it that it's an
asynchronous command? or should we add an extra piece of information into 
the MI output command stating that the command is asynchronous. 
For instance,

  47*stopped,asynchronous,reason="end-stepping-range",thread-id="0", ...

Thanks,
Bob Rossi