MI output command error

MI output command error

[Bob Rossi]

Hi,

The doco for -break-watch has,
   (gdb)
   -break-watch x
   ^done,wpt={number="2",exp="x"}
   (gdb)
   -exec-continue
   ^running
   ^done,reason="watchpoint-trigger",wpt={number="2",exp="x"},
   value={old="-268439212",new="55"},
   frame={func="main",args=[],file="recursive2.c",line="5"}
   (gdb)

However, when I run it with GDB from CVS, I get,

   (gdb) 
   -break-watch argc
   ^done,wpt={number="2",exp="argc"}
   (gdb) 
   -exec-continue
   ^running
   (gdb) 
   *stopped,reason="watchpoint-scope",wpnum="2",thread-id="0",frame={addr="0x40039dc9",func="__libc_start_main",args=[],from="/lib/libc.so.6"}
   (gdb) 

The problem is, the -exec-continue command in CVS has an extra '(gdb)'
in it after '^running'. I don't know if the doco or GDB is correct.
I do know that I think GDB is conforming to the MI output command
syntax, even though I think the documentation output looks more correct.

Was the extra "(gdb)" added to make the output command match the syntax?
Is this a bug in the doco or in GDB?

Thanks,
Bob Rossi

Re: MI output command error

[Bob Rossi]

On Tue, Mar 08, 2005 at 09:39:57PM -0500, Bob Rossi wrote:
> Hi,
> 
> The doco for -break-watch has,
>    (gdb)
>    -break-watch x
>    ^done,wpt={number="2",exp="x"}
>    (gdb)
>    -exec-continue
>    ^running
>    ^done,reason="watchpoint-trigger",wpt={number="2",exp="x"},
>    value={old="-268439212",new="55"},
>    frame={func="main",args=[],file="recursive2.c",line="5"}
>    (gdb)
> 
> However, when I run it with GDB from CVS, I get,
> 
>    (gdb) 
>    -break-watch argc
>    ^done,wpt={number="2",exp="argc"}
>    (gdb) 
>    -exec-continue
>    ^running
>    (gdb) 
>    *stopped,reason="watchpoint-scope",wpnum="2",thread-id="0",frame={addr="0x40039dc9",func="__libc_start_main",args=[],from="/lib/libc.so.6"}
>    (gdb) 
> 
> The problem is, the -exec-continue command in CVS has an extra '(gdb)'
> in it after '^running'. I don't know if the doco or GDB is correct.
> I do know that I think GDB is conforming to the MI output command
> syntax, even though I think the documentation output looks more correct.
> 
> Was the extra "(gdb)" added to make the output command match the syntax?
> Is this a bug in the doco or in GDB?

Sorry to respond to my own Email, but the more I thought about it, I
realized that what GDB was outputting was definatly a bug. The
documentation is also incorrect. So, something will have to change in
order to get this output correct.

There is no way 1 MI input command can result in more than one MI output
commands. The front end would probably send 1 command, after it got back
the first "(gdb)", and then send another command for the second time.
This would cause the front end's buffer to get out of sync with GDB.

I'll look into fixing this when I get more time. If anyone think's that
this is not a problem, please let me know why.

Thanks,
Bob Rossi

Re[2]: MI output command error

[Konstantin Karganov]

Hello Bob,

> There is no way 1 MI input command can result in more than one MI output
> commands. The front end would probably send 1 command, after it got back
> the first "(gdb)", and then send another command for the second time.
> This would cause the front end's buffer to get out of sync with GDB.

> If anyone think's that this is not a problem, please let me know why.
I think that is not a problem. Look, in MI specification there are special
records for status-async-output ("information about the progress of
slow operation") and notify-async-output ("supplementary information
that the client should handle"). From these descriptions it is clearly
possible, that this records can be multiple (say, a progress of a very
slow operation :) ) plus the result-record for the command.

Another similar hint is that there are (oob-record)* in output rule.
Though it doesn't make several messages now, who knows all the use
cases and how it will behave in the next versions...

For myself, I decided to ignore "(gdb)" strings and wait for the
appropriate result-record (it will always appear, according to
grammar), collecting passing async-records at the same time.

I suppose that the only way to get in line with GDB responses is to
keep track of message tokens. And implementing the GUI frontend you
will have to use tokens anyhow.

-- 
Best regards,
 Konstantin 

Re: MI output command error

[Bob Rossi]

On Thu, Mar 10, 2005 at 12:36:42PM +0300, Konstantin Karganov wrote:
> Hello Bob,
> 
> > There is no way 1 MI input command can result in more than one MI output
> > commands. The front end would probably send 1 command, after it got back
> > the first "(gdb)", and then send another command for the second time.
> > This would cause the front end's buffer to get out of sync with GDB.
> 
> > If anyone think's that this is not a problem, please let me know why.
> I think that is not a problem. Look, in MI specification there are special
> records for status-async-output ("information about the progress of
> slow operation") and notify-async-output ("supplementary information
> that the client should handle"). From these descriptions it is clearly
> possible, that this records can be multiple (say, a progress of a very
> slow operation :) ) plus the result-record for the command.

Yeah, that's what I was thinking. So the '^running' should be replaced
with an '*running' and the extra "(gdb)" should probably be removed. The
problem is finding all the case's that do this and converting them so
that the syntax is still correct. 

> Another similar hint is that there are (oob-record)* in output rule.
> Though it doesn't make several messages now, who knows all the use
> cases and how it will behave in the next versions...

Yeah, the way I'm saying to fix this problem would end up using that
feature.

> For myself, I decided to ignore "(gdb)" strings and wait for the
> appropriate result-record (it will always appear, according to
> grammar), collecting passing async-records at the same time.
> 
> I suppose that the only way to get in line with GDB responses is to
> keep track of message tokens. And implementing the GUI frontend you
> will have to use tokens anyhow.

Yeah, but even using the TOKENS doesn't work. The problem is, whenver I
front end get's a "(gdb)\r\n" it knows that it can send another command.
When you use the tokens with this command, you end up with,

   (gdb) 
   444-exec-continue
   444^running
   (gdb) 
   444*stopped,reason="watchpoint-scope",wpnum="2",thread-id="0",frame={addr="0x40039dc9",func="__libc_start_main",args=[],from="/lib/libc.so.6"}
   (gdb) 

This is still incorrect. The front end would have to know that the first
MI output command was not the end of the output from the single MI
input command. In other words, the FE would have to hardcode the fact
that the -exec-contine command may output 2 MI output commands. This
can't be correct, it would be better if the output is changed to,

   (gdb) 
   444-exec-continue
   444*running
   444*stopped,reason="watchpoint-scope",wpnum="2",thread-id="0",frame={addr="0x40039dc9",func="__libc_start_main",args=[],from="/lib/libc.so.6"}
   (gdb) 

That would at least be a start.

Thanks,
Bob Rossi

Re: MI output command error

[Karganov Konstantin]

> Yeah, but even using the TOKENS doesn't work. The problem is, whenver I
> front end get's a "(gdb)\r\n" it knows that it can send another command.
> When you use the tokens with this command, you end up with,
> 
>    (gdb) 
>    444-exec-continue
>    444^running
>    (gdb) 
>    444*stopped,reason="watchpoint-scope",wpnum="2",thread-id="0",frame={addr="0x40039dc9",func="__libc_start_main",args=[],from="/lib/libc.so.6"}
>    (gdb) 
> 
> This is still incorrect. The front end would have to know that the first
> MI output command was not the end of the output from the single MI
> input command. In other words, the FE would have to hardcode the fact
> that the -exec-continue command may output 2 MI output commands. This
> can't be correct, it would be better if the output is changed to,

If I were the GDB maintainer, I'd answer the following:
All "execution" commands (continue, step, next, etc) are partially 
asynchronous - in the sence that when the execution is started you can 
type a characters to inferior stdin. In this case you need a way to know 
when the inferior starts/stops execution.

In GDB the execution commands behave like this - you get a confirmation 
(^running) when the execution has started (at this time the command is 
assumed to be accomplished) and you get the notification on inferior state 
change some time later (*stopped).

So, working over MI you need to handle all execution commands in a way, 
that assumes "^running" as a beginning of execution and waits for 
"*stopped" for execution end. That's all.

On the other hand, it would be more logical if the execution commands were 
considered accomplished only after execution completion (i.e. *running and 
^stopped), but I think there was a reason to choose the way it was 
actually implemented.

Konstantin.

PS. all this resembles a group of savages, gathered around something 
unusual and discussing what could it be used for and guessing what it 
actually is... :)

Re: MI output command error

[Bob Rossi]

On Thu, Mar 10, 2005 at 04:36:59PM +0300, Karganov Konstantin wrote:
> 
> > Yeah, but even using the TOKENS doesn't work. The problem is, whenver I
> > front end get's a "(gdb)\r\n" it knows that it can send another command.
> > When you use the tokens with this command, you end up with,
> > 
> >    (gdb) 
> >    444-exec-continue
> >    444^running
> >    (gdb) 
> >    444*stopped,reason="watchpoint-scope",wpnum="2",thread-id="0",frame={addr="0x40039dc9",func="__libc_start_main",args=[],from="/lib/libc.so.6"}
> >    (gdb) 
> > 
> > This is still incorrect. The front end would have to know that the first
> > MI output command was not the end of the output from the single MI
> > input command. In other words, the FE would have to hardcode the fact
> > that the -exec-continue command may output 2 MI output commands. This
> > can't be correct, it would be better if the output is changed to,
> 
> If I were the GDB maintainer, I'd answer the following:
> All "execution" commands (continue, step, next, etc) are partially 
> asynchronous - in the sence that when the execution is started you can 
> type a characters to inferior stdin. In this case you need a way to know 
> when the inferior starts/stops execution.

Are you suggesting that you are using the MI with putting the inferior
on a separate pty?

Thanks,
Bob Rossi

Re: MI output command error

[Karganov Konstantin]

> > If I were the GDB maintainer, I'd answer the following:
> > All "execution" commands (continue, step, next, etc) are partially 
> > asynchronous - in the sence that when the execution is started you can 
> > type a characters to inferior stdin. In this case you need a way to know 
> > when the inferior starts/stops execution.
> 
> Are you suggesting that you are using the MI with putting the inferior
> on a separate pty?

I suppose, that it is implemented in the same way. I mean that redirection 
of inferior's I/O makes just redirection and doesnt affect the way in 
which gdb command processing is done.

And it should be independent of tty redirection!
You will be scolding first if after using "tty" command the 
^running/*stopped will change to *running/^stopped... :)

Best regards,
Konstantin.

Re: MI output command error

[Bob Rossi]

On Thu, Mar 10, 2005 at 05:06:35PM +0300, Karganov Konstantin wrote:
> 
> > > If I were the GDB maintainer, I'd answer the following:
> > > All "execution" commands (continue, step, next, etc) are partially 
> > > asynchronous - in the sence that when the execution is started you can 
> > > type a characters to inferior stdin. In this case you need a way to know 
> > > when the inferior starts/stops execution.
> > 
> > Are you suggesting that you are using the MI with putting the inferior
> > on a separate pty?
> 
> I suppose, that it is implemented in the same way. I mean that redirection 
> of inferior's I/O makes just redirection and doesnt affect the way in 
> which gdb command processing is done.
> 
> And it should be independent of tty redirection!
> You will be scolding first if after using "tty" command the 
> ^running/*stopped will change to *running/^stopped... :)

haha :)

No, seriously though. Here is how I imagine a transaction between a FE 
and GDB.

   -> GDB alerts FE it is ready for a command via "(gdb)\r\n"
   -> FE sends a single MI input command
   -> FE does I/O with inferior
   -> GDB sends an MI output command
   -> GDB alerts FE it is ready for a command via "(gdb)\r\n"

So, the only time a FE would know that it is ready to send a command is
when it reaches the "(gdb)". Is this the same model for you?

That's why I think the output

   (gdb)
   444-exec-continue
   444*running
   444*stopped...
   (gdb)

is better.

Thanks,
Bob Rossi

Re: MI output command error

[Karganov Konstantin]

> Here is how I imagine a transaction between a FE and GDB.
> 
>    -> GDB alerts FE it is ready for a command via "(gdb)\r\n"
>    -> FE sends a single MI input command
>    -> FE does I/O with inferior
>    -> GDB sends an MI output command
>    -> GDB alerts FE it is ready for a command via "(gdb)\r\n"
> 
> So, the only time a FE would know that it is ready to send a command is
> when it reaches the "(gdb)". Is this the same model for you?
> 
> That's why I think the output
> 
>    (gdb)
>    444-exec-continue
>    444*running
>    444*stopped...
>    (gdb)
> 
> is better.

I suppose that no one is going to change the existing behavior

 444-exec-continue
 444^running
 (gdb)
 444*stopped
 (gdb)

at least for historical reasons. And again - for uniformity with the 
human-oriented gdb output and the case of sharing the tty with inferior. 

If so, I suggest the following model of interaction with gdb:

 -> FE starts gdb and reads its output (there could be startup error msgs)
 -> FE sends a MI command and waits for its completion
 -> gdb sends a sequence of responses (there can be an automatic displays, 
    for example. (oob_rec)* is really needed, there can be any 
    number of the messages!)
    we are waiting for ^-response.
    if we get ^running (for execution commands) we start waiting for 
    *stopped one.
    getting the response we always skip "(gdb)" line.

Meanwhile the inferior tty works independently (in other
thread/window of FE, for example). ANd it seems to me that making a FE 
over gdb you surely need to redirect the inferior I/O somewhere.

Konstantin.

RE: MI output command error

[Dave Korn]

----Original Message----
>From: Bob Rossi
>Sent: 10 March 2005 14:40

> No, seriously though. Here is how I imagine a transaction between a FE
> and GDB.
> 
>    -> GDB alerts FE it is ready for a command via "(gdb)\r\n"
>    -> FE sends a single MI input command
>    -> FE does I/O with inferior
>    -> GDB sends an MI output command
>    -> GDB alerts FE it is ready for a command via "(gdb)\r\n"

  Your imagination unfortunately fails to correspond to reality.  This is
*your* fault, not reality's.  What part of "asynchronous" don't you
understand?

> That's why I think the output
> 
>    (gdb)
>    444-exec-continue
>    444*running
>    444*stopped...
>    (gdb)
> 
> is better.

  Well, you're wrong.  "running" is the output from the exec-continue
command and it is synchronous: the exec-continue command executes, starts up
the inferior, prints out "running", and is then complete.  At that point the
inferior is running, but regardless of that, gdb is ready to take more
commands and so should prompt you.  The "stopped" output is an asynchronous
notification of an event that occurred while the inferior was running, but
that in no sense makes it output from the "exec-continue" command.  It can
occur spontaneously, it can happen sooner or later or not at all, and your
model of the interaction between FE and MI as being a completely predictable
one-command-one-reply set of exchanges is inaccurate, incomplete, and
inadequate to the task.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: MI output command error

['Bob Rossi']

> > That's why I think the output
> > 
> >    (gdb)
> >    444-exec-continue
> >    444*running
> >    444*stopped...
> >    (gdb)
> > 
> > is better.
> 
>   Well, you're wrong.  "running" is the output from the exec-continue
> command and it is synchronous: the exec-continue command executes, starts up
> the inferior, prints out "running", and is then complete.  At that point the
> inferior is running, but regardless of that, gdb is ready to take more
> commands and so should prompt you.  

It is? It is still busy executing the inferior. I was under the
impression GDB was somehow "busy" while executing the inferior. Is this
not true?

> The "stopped" output is an asynchronous
> notification of an event that occurred while the inferior was running, but
> that in no sense makes it output from the "exec-continue" command.  

Well, GDB says that it is output from the -exec-continue command. It's 
asyncronous output. That's why the TOKEN 444 is before the *stopped.

Bob Rossi

Re: MI output command error

[Daniel Jacobowitz]

On Thu, Mar 10, 2005 at 11:08:52AM -0500, 'Bob Rossi' wrote:
> > > That's why I think the output
> > > 
> > >    (gdb)
> > >    444-exec-continue
> > >    444*running
> > >    444*stopped...
> > >    (gdb)
> > > 
> > > is better.
> > 
> >   Well, you're wrong.  "running" is the output from the exec-continue
> > command and it is synchronous: the exec-continue command executes, starts up
> > the inferior, prints out "running", and is then complete.  At that point the
> > inferior is running, but regardless of that, gdb is ready to take more
> > commands and so should prompt you.  
> 
> It is? It is still busy executing the inferior. I was under the
> impression GDB was somehow "busy" while executing the inferior. Is this
> not true?

Not necessarily; some targets are asynhronous.

> > The "stopped" output is an asynchronous
> > notification of an event that occurred while the inferior was running, but
> > that in no sense makes it output from the "exec-continue" command.  
> 
> Well, GDB says that it is output from the -exec-continue command. It's 
> asyncronous output. That's why the TOKEN 444 is before the *stopped.

If it is asynchronous, that presumably means GDB is willing to accept
input.... by definition even.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI output command error

[Bob Rossi]

On Thu, Mar 10, 2005 at 11:13:09AM -0500, Daniel Jacobowitz wrote:
> On Thu, Mar 10, 2005 at 11:08:52AM -0500, 'Bob Rossi' wrote:
> > > > That's why I think the output
> > > > 
> > > >    (gdb)
> > > >    444-exec-continue
> > > >    444*running
> > > >    444*stopped...
> > > >    (gdb)
> > > > 
> > > > is better.
> > > 
> > >   Well, you're wrong.  "running" is the output from the exec-continue
> > > command and it is synchronous: the exec-continue command executes, starts up
> > > the inferior, prints out "running", and is then complete.  At that point the
> > > inferior is running, but regardless of that, gdb is ready to take more
> > > commands and so should prompt you.  
> > 
> > It is? It is still busy executing the inferior. I was under the
> > impression GDB was somehow "busy" while executing the inferior. Is this
> > not true?
> 
> Not necessarily; some targets are asynhronous.

Hi Daniel,

The whole idea of GDB being asyncronous is new to me. Up until now, I
have been very content thinking that GDB would become "busy" whenver the
inferior was started up to do some work.

I would really like to understand the concept and the reason why GDB had
to have the asyncronous feature. While looking for documentation on GDB 
being asyncronous, I've only found very little. A grep of gdb.texino 
yeilded me nothing interesting.

I noticed that the command line option is not documented in the manual.
Which made me think it didn't exist. However, when I run gdb --help,
it's there.  
   gdb --help
   --[no]async        Enable (disable) asynchronous version of CLI

When I try to use the option, it fails,

$ gdb --async ./main
gdb: unrecognized option `--async'
Use `gdb --help' for a complete list of options.

$ gdb --noasync ./main
gdb: unrecognized option `--noasync'
Use `gdb --help' for a complete list of options.

Am I doing something wrong?

Thanks,
Bob Rossi

Re: MI output command error

[Daniel Jacobowitz]

On Thu, Mar 10, 2005 at 12:44:08PM -0500, Bob Rossi wrote:
> Hi Daniel,
> 
> The whole idea of GDB being asyncronous is new to me. Up until now, I
> have been very content thinking that GDB would become "busy" whenver the
> inferior was started up to do some work.
> 
> I would really like to understand the concept and the reason why GDB had
> to have the asyncronous feature. While looking for documentation on GDB 
> being asyncronous, I've only found very little. A grep of gdb.texino 
> yeilded me nothing interesting.

Sorry, I don't know anything more about async mode than is in the
documentation (and mailing list archives - it has come up plenty of
times).

It shouldn't take much thinking to understand why asynchronous
operation is desirable.  A user interface is _always_ asynchronous,
because your human user never blocks.

I'm as mystified as Dave as to how you could read the manual and
believe GDB/MI was designed to operate synchronously.  A number of MI
commands have documentation that begins with "Asynchronous command." In
particular, look at -exec-interrupt, which makes no sense as a
synchronous command.

> I noticed that the command line option is not documented in the manual.
> Which made me think it didn't exist. However, when I run gdb --help,
> it's there.  
>    gdb --help
>    --[no]async        Enable (disable) asynchronous version of CLI
> 
> When I try to use the option, it fails,
> 
> $ gdb --async ./main
> gdb: unrecognized option `--async'
> Use `gdb --help' for a complete list of options.
> 
> $ gdb --noasync ./main
> gdb: unrecognized option `--noasync'
> Use `gdb --help' for a complete list of options.
> 
> Am I doing something wrong?

2004-07-16  Andrew Cagney  <cagney@gnu.org>

        * defs.h (event_loop_p): Replace variable declaration with macro,
        always 1.
        * main.c (captured_main): Delete options "-async" and "-noasync".
        (event_loop_p): Delete variable.
        * NEWS: Mention that "-async" and "-noasync" were removed.

He missed --help; please fix that.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI output command error

[Bob Rossi]

> I'm as mystified as Dave as to how you could read the manual and
> believe GDB/MI was designed to operate synchronously.  A number of MI
> commands have documentation that begins with "Asynchronous command." In
> particular, look at -exec-interrupt, which makes no sense as a
> synchronous command.

Hey, I'm still learning here, just make sure you don't confuse
mystified/stupid :)

I've been used to working with the a2 interace, which wasn't
asyncronous. Do you guys know if the MI always works asyncronously? Or
are there modes when it has to work syncronously?

Thanks,
Bob Rossi

Re: MI output command error

[Daniel Jacobowitz]

On Thu, Mar 10, 2005 at 03:47:38PM -0500, Bob Rossi wrote:
> > I'm as mystified as Dave as to how you could read the manual and
> > believe GDB/MI was designed to operate synchronously.  A number of MI
> > commands have documentation that begins with "Asynchronous command." In
> > particular, look at -exec-interrupt, which makes no sense as a
> > synchronous command.
> 
> Hey, I'm still learning here, just make sure you don't confuse
> mystified/stupid :)
> 
> I've been used to working with the a2 interace, which wasn't
> asyncronous.

What do you mean by "a2"?

> Do you guys know if the MI always works asyncronously? Or
> are there modes when it has to work syncronously?

_MI_ is defined to be asynchronous.  Any asynchronous interface may
appear synchronous under some conditions.

How asynchronous it is depends on the target; most targets are not
fully async.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI output command error

[Bob Rossi]

On Thu, Mar 10, 2005 at 04:08:48PM -0500, Daniel Jacobowitz wrote:
> On Thu, Mar 10, 2005 at 03:47:38PM -0500, Bob Rossi wrote:
> > > I'm as mystified as Dave as to how you could read the manual and
> > > believe GDB/MI was designed to operate synchronously.  A number of MI
> > > commands have documentation that begins with "Asynchronous command." In
> > > particular, look at -exec-interrupt, which makes no sense as a
> > > synchronous command.
> > 
> > Hey, I'm still learning here, just make sure you don't confuse
> > mystified/stupid :)
> > 
> > I've been used to working with the a2 interace, which wasn't
> > asyncronous.
> 
> What do you mean by "a2"?

Annotate 2

> > Do you guys know if the MI always works asyncronously? Or
> > are there modes when it has to work syncronously?
> 
> _MI_ is defined to be asynchronous.  Any asynchronous interface may
> appear synchronous under some conditions.
> 
> How asynchronous it is depends on the target; most targets are not
> fully async.

Thanks for the help, it is *very* much appreciated.

Bob Rossi

RE: MI output command error

[Dave Korn]

----Original Message----
>From: 'Bob Rossi'
>Sent: 10 March 2005 16:09

>>> That's why I think the output
>>> 
>>>    (gdb)
>>>    444-exec-continue
>>>    444*running
>>>    444*stopped...
>>>    (gdb)
>>> 
>>> is better.
>> 
>>   Well, you're wrong.  "running" is the output from the exec-continue
>> command and it is synchronous: the exec-continue command executes,
>> starts up the inferior, prints out "running", and is then complete.  At
>> that point the inferior is running, but regardless of that, gdb is ready
>> to take more commands and so should prompt you.
> 
> It is? It is still busy executing the inferior. I was under the
> impression GDB was somehow "busy" while executing the inferior. Is this
> not true?

  Hell no!  Gdb is waiting for input from you.  Send it a command - e.g.
"info program", which wouldn't need to tell you if the inferior was running
or stopped if it was only possible to send gdb commands while the inferior
was stopped.  Some things are disabled while the inferior is running, others
aren't.  Blimey, if you aren't aware of that it's no wonder this
conversation has been going at cross purposes!  Check the documentation,
take a look at the -async flag for example.  And read the section on "GDB/MI
result records", which makes it clear that if you see "^running" that means
that an asynchronous operation is under way but not completed.  Then read
the documentation under "GDB/MI Program control", where it explains that
-exec-continue is *asynchronous*.  Oh, wait a minute, you must have already
read that because you quoted the example from it.  Do you actually know what
the terms "asynchronous" and "synchronous" mean, or were you just kind of
skimming over bits that didn't make any sense to you as you read the docs?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: MI output command error

[Daniel Jacobowitz]

On Thu, Mar 10, 2005 at 04:22:50PM -0000, Dave Korn wrote:
>  Do you actually know what
> the terms "asynchronous" and "synchronous" mean, or were you just kind of
> skimming over bits that didn't make any sense to you as you read the docs?

Same rules apply to you as anyone else, Dave.  Please make an effort to
be polite on this list.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: MI output command error

[Dave Korn]

----Original Message----
>From: Daniel Jacobowitz
>Sent: 10 March 2005 16:33

> On Thu, Mar 10, 2005 at 04:22:50PM -0000, Dave Korn wrote:
>>  Do you actually know what
>> the terms "asynchronous" and "synchronous" mean, or were you just kind of
>> skimming over bits that didn't make any sense to you as you read the
>> docs? 
> 
> Same rules apply to you as anyone else, Dave.  Please make an effort to
> be polite on this list.

  Sorry Bob, and all, that wasn't meant to sound quite how it came out.  Let
me try and explain myself better.

  It's common enough, when people are reading very technical documents and
come across technical terms that they aren't familiar with, to try and make
sense of the documentation by skipping over the unknown jargon and trying to
make sense of the rest of the context around it.

  This is a reasonable strategy that works well enough often enough that
that's why people use it, but sometimes (as in the difference between
'synchronous' and 'asynchronous') it may lead people to overlook a subtle
distinction that radically changes the final meaning of the
sentence/paragraph/whatever.

  So it occurred to me that maybe Bob had just skimmed over that bit,
without realising the significance of the term, and I was _trying_ just to
ask in a straightforward fashion if that was what had happened.  Pardon me
for not finding a more finely-worded way of asking the question, but it
wasn't in any sense meant to be a flame.  (Please note how I didn't use any
insults, swearwords, or pejoratives; it really was just a straight
question).


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: MI output command error

['Bob Rossi']

On Thu, Mar 10, 2005 at 04:48:32PM -0000, Dave Korn wrote:
> ----Original Message----
> >From: Daniel Jacobowitz
> >Sent: 10 March 2005 16:33
> 
> > On Thu, Mar 10, 2005 at 04:22:50PM -0000, Dave Korn wrote:
> >>  Do you actually know what
> >> the terms "asynchronous" and "synchronous" mean, or were you just kind of
> >> skimming over bits that didn't make any sense to you as you read the
> >> docs? 
> > 
> > Same rules apply to you as anyone else, Dave.  Please make an effort to
> > be polite on this list.
> 
>   Sorry Bob, and all, that wasn't meant to sound quite how it came out.  Let
> me try and explain myself better.
> 
>   It's common enough, when people are reading very technical documents and
> come across technical terms that they aren't familiar with, to try and make
> sense of the documentation by skipping over the unknown jargon and trying to
> make sense of the rest of the context around it.
> 
>   This is a reasonable strategy that works well enough often enough that
> that's why people use it, but sometimes (as in the difference between
> 'synchronous' and 'asynchronous') it may lead people to overlook a subtle
> distinction that radically changes the final meaning of the
> sentence/paragraph/whatever.
> 
>   So it occurred to me that maybe Bob had just skimmed over that bit,
> without realising the significance of the term, and I was _trying_ just to
> ask in a straightforward fashion if that was what had happened.  Pardon me
> for not finding a more finely-worded way of asking the question, but it
> wasn't in any sense meant to be a flame.  (Please note how I didn't use any
> insults, swearwords, or pejoratives; it really was just a straight
> question).

Thanks Dave, I also thought you were a little angry at me too :)
No hard feelings.

So, I see your point now. See, I've never used GDB with the -async
flag, or when GDB was actually acting asyncronously. When I read the
term 'asyncronous/syncronous' I read them as 'getting data you didn't
ask for/getting data you did ask for'.

Now I have a whole slew of questions that I need the answer to, this
could probably go right up on the doco under, FE FAQ.

What is the intention of the -async flag as it relates to GDB/MI? 
What problem does it solve(why is it needed)?
Will GDB use it's asyncronous behavior by default on some systems?
   or do I have to explicitly tell it to act that way?
Are MI FE developers supposed to be using the -async flat?

See, as I'm working on improving the MI testsuite, I didn't even come
across the async flag, which tells me that it is completely untested.
Should it be tested or should MI FE developers not be using it?

Thanks,
Bob Rossi

Re[2]: MI output command error

[Konstantin Karganov]

Hello Bob,

> Now I have a whole slew of questions that I need the answer to, this
> could probably go right up on the doco under, FE FAQ.

> What is the intention of the -async flag as it relates to GDB/MI? 
> What problem does it solve(why is it needed)?
> Are MI FE developers supposed to be using the -async flag?

In fact, there are 2 basic models of inferior exectuion control:
synchronous and asynchronous. Consider the example of step command:

- Synchronous step means that you issue a command and wait for its
 completion. The most wonderful things here is that you always know
 the state of the debuggee, you know when and where it started and
 stopped its execution and when the step has finished, the state of the
 inferior is fixed and you can analyze it. The problem appears if the
 step has blocked (i.e. at endless loop or communication) - you need to
 interrupt the inferior and try to dig out the cause of the problem.

- Asynchronous step means that as you issue a command the debuggee
 starts to execute and at the same time you get the control and can
 issue other commands. The interface doesn't block and always remain
 responsive, but the problems are clear - you don't see the state of
 the inferior, since it is changing and can't get what's going on
 there, you don't know when the step has finished, you can't probably
 issue some commands (i.e. set variable).

For human operating a debugger the synchronous model looks more
natural and usable - s/he issues commands sequentially and always
keeps track of what is going on inside.

For the GUI wrapper, on the contrary, asynchronous model seems to be
preferrable - GUI is an asynchronous thing and it is expected to
display information even if the execution is in progress. The question
is - what you can display during the inferior execution and does it
make sense (because the process state is changing quickly).

My first posts to this list were exactly on the (a)synchronous gdb mode
and the possible commands during the inferior execution. In practice
it turned out that gdb behaves synchronously (gdb 5.0 accepts the
-async option, but it doesn't affect anything when debugging local
target, and gdb 6.3 refuses to recognize -async switch).

That is not a severe problem if you can interrupt the execution,
display what needed and then continue preforming previous command, but
in gdb you can't interrupt the execution (in synchronous mode there is
no sence in issuing -exec-interrupt, sinse gdb doesn't listen for
commands) and sending SIGINT from another terminal doesn't help
(why??) and also there is no documented way to continue the
interrupted execution transparently.

So, the -async flag could solve some problems, but here is one problem
- it doesn't work itself. And also another unclear point - how to
interrupt the execution and restore from the interrupt (assumed that
the gdb is controlled by other application through the pipe or socket).

It is not crucial for the user operating the debugger, but for
implementing a FE some functions of the kind would be appreciated...

-- 
Best regards,
 Konstantin