Re: MI output command error

Re: MI output command error

[Jim Ingham]

Eli is right, gdb was changed to HAVE an event loop, which made  
handling async targets possible.  But then the target itself needed  
to be made asynchronous as well.  There is a remote async target  
already, though I don't know how well it works.  For a ptrace based  
target (most native targets) you need to have a separate thread to  
run wait4 which then communicates back to the event source through  
some kind of signal. For procfs, I bet it would be even easier, since  
then you could just make an event source for the various proc files  
you need to watch and add them to the general "select" call that also  
waits for command input.

We made this work (for a ptrace-like setup) on Mac OS X.  There were  
a bunch of little bugs we had to deal with (like breakpoint commands  
that can restart the target are a little tricky when you have an  
async target).  There was a bunch of fiddling necessary to make it  
stable, but it wasn't all that hard.  It certainly is useful from a  
GUI to be able to interrupt, and almost more important to be able to  
ask gdb "are you running the target or not?" which can help sync up  
the GUI if things get confused as they sometimes do...

Jim

On Mar 12, 2005, at 11:39 AM, gdb-digest-help@sources.redhat.com wrote:

>> From: Nick Roberts <nickrob@snap.net.nz>
>> Date: Sat, 12 Mar 2005 10:49:41 +1300
>> Cc: Dave Korn <dave.korn@artimi.com>,
>>     Karganov Konstantin <kostik@ispras.ru>, GDB  
>> <gdb@sources.redhat.com>
>>
>>> Lack of implementation.  No one's done the work.
>>
>> Thats understandable. However, given that MI was introduced in GDB  
>> 5.0, I
>> think there should be something in the manual explaining this as  
>> it seems to
>> create a lot of confusion. It needs to be written by someone who  
>> understands
>> the issue i.e not myself.
>
> I'm all for documenting this in some useful way, but I fail to see how
> could this be done.  Describing the async operation itself is already
> a big challenge, as the details are extremely confusing, unless you've
> read the code several times and have a good understanding of the
> underlying system calls (like `poll' and `select').  Differences
> between interpreters add another dimension of complexity to this.
>
>> I believe that operation is asynchronous with certain targets,
>> although I have never managed to create these conditions, even with
>> gdbserver over TCP.
>
> Actually, I think that the asynchronous operation is independent of
> the target.  The infrastructure for this is in event-loop.c, which is
> not specific to any target.
>
> The problem with implementing async operation with the CLI interface
> is, AFAIU, not its dependence on some target-specific feature, but
> rather the need to redesig the CLI front end to do something useful
> while waiting for a prolonged operation to run to completion.  For GUI
> front ends, such as those who use MI, it's clear what to do during
> that time, and the separate-process implementation makes it even
> easier to design.  By contrast, the CLI interface is part of the GDB
> process.
>
> I don't consider myself a specialist in these matters, so please take
> the above with a grain of salt (i.e., it might all be wrong ;-).
>

Re: MI output command error

[Nick Roberts]

> 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 think the problem that people like Bob and myself have with this, is that
when GDB is compiled out of the box, it doesn't operate asynchronously. So
if we run GDB using MI, -exec-interrupt *doesn't* interrupt the inferior:
...
^done
(gdb) 
111-exec-continue
111^running
(gdb) 
222-exec-interrupt

Dave Korn's explanation is very helpful. Considering the MI output to be
asynchronous, makes it much easier to understand. The fact remains, however,
that for native targets at least (the most common configuration?), operation
is synchronous. It leads me to wonder how this discrepancy arises.

Nick

Re: MI output command error

[Daniel Jacobowitz]

On Sat, Mar 12, 2005 at 10:03:55AM +1300, Nick Roberts 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.
> 
> I think the problem that people like Bob and myself have with this, is that
> when GDB is compiled out of the box, it doesn't operate asynchronously. So
> if we run GDB using MI, -exec-interrupt *doesn't* interrupt the inferior:
> ...
> ^done
> (gdb) 
> 111-exec-continue
> 111^running
> (gdb) 
> 222-exec-interrupt
> 
> Dave Korn's explanation is very helpful. Considering the MI output to be
> asynchronous, makes it much easier to understand. The fact remains, however,
> that for native targets at least (the most common configuration?), operation
> is synchronous. It leads me to wonder how this discrepancy arises.

Lack of implementation.  No one's done the work.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI output command error

[Bob Rossi]

On Fri, Mar 11, 2005 at 04:30:43PM -0500, Daniel Jacobowitz wrote:
> On Sat, Mar 12, 2005 at 10:03:55AM +1300, Nick Roberts 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.
> > 
> > I think the problem that people like Bob and myself have with this, is that
> > when GDB is compiled out of the box, it doesn't operate asynchronously. So
> > if we run GDB using MI, -exec-interrupt *doesn't* interrupt the inferior:
> > ...
> > ^done
> > (gdb) 
> > 111-exec-continue
> > 111^running
> > (gdb) 
> > 222-exec-interrupt
> > 
> > Dave Korn's explanation is very helpful. Considering the MI output to be
> > asynchronous, makes it much easier to understand. The fact remains, however,
> > that for native targets at least (the most common configuration?), operation
> > is synchronous. It leads me to wonder how this discrepancy arises.
> 
> Lack of implementation.  No one's done the work.

So currently, is it best to realize that the MI protocol is asynchronous,
but to treat GDB as if it's executing syncronously?

Basically, send commands to GDB as if the MI interface was synchronous?

Bob Rossi

Re: MI output command error

[Daniel Jacobowitz]

On Fri, Mar 11, 2005 at 04:36:27PM -0500, Bob Rossi wrote:
> On Fri, Mar 11, 2005 at 04:30:43PM -0500, Daniel Jacobowitz wrote:
> > On Sat, Mar 12, 2005 at 10:03:55AM +1300, Nick Roberts 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.
> > > 
> > > I think the problem that people like Bob and myself have with this, is that
> > > when GDB is compiled out of the box, it doesn't operate asynchronously. So
> > > if we run GDB using MI, -exec-interrupt *doesn't* interrupt the inferior:
> > > ...
> > > ^done
> > > (gdb) 
> > > 111-exec-continue
> > > 111^running
> > > (gdb) 
> > > 222-exec-interrupt
> > > 
> > > Dave Korn's explanation is very helpful. Considering the MI output to be
> > > asynchronous, makes it much easier to understand. The fact remains, however,
> > > that for native targets at least (the most common configuration?), operation
> > > is synchronous. It leads me to wonder how this discrepancy arises.
> > 
> > Lack of implementation.  No one's done the work.
> 
> So currently, is it best to realize that the MI protocol is asynchronous,
> but to treat GDB as if it's executing syncronously?
> 
> Basically, send commands to GDB as if the MI interface was synchronous?

I don't know what's best.  I've never implemented anything having to do
with MI.  You, as the man on the ground, get to decide that :-)

"Best" would presumably be to implement async operation in GDB; I have
no idea what's involved.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI output command error

[Nick Roberts]

 > > Dave Korn's explanation is very helpful. Considering the MI output to be
 > > asynchronous, makes it much easier to understand. The fact remains,
 > > however, that for native targets at least (the most common
 > > configuration?), operation is synchronous. It leads me to wonder how this
 > > discrepancy arises.
 > 
 > Lack of implementation.  No one's done the work.

Thats understandable. However, given that MI was introduced in GDB 5.0, I
think there should be something in the manual explaining this as it seems to
create a lot of confusion. It needs to be written by someone who understands
the issue i.e not myself. I believe that operation is asynchronous with
certain targets, although I have never managed to create these conditions,
even with gdbserver over TCP.

Nick

Re: MI output command error

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 12 Mar 2005 10:49:41 +1300
> Cc: Dave Korn <dave.korn@artimi.com>,
> 	Karganov Konstantin <kostik@ispras.ru>, GDB <gdb@sources.redhat.com>
> 
>  > Lack of implementation.  No one's done the work.
> 
> Thats understandable. However, given that MI was introduced in GDB 5.0, I
> think there should be something in the manual explaining this as it seems to
> create a lot of confusion. It needs to be written by someone who understands
> the issue i.e not myself.

I'm all for documenting this in some useful way, but I fail to see how
could this be done.  Describing the async operation itself is already
a big challenge, as the details are extremely confusing, unless you've
read the code several times and have a good understanding of the
underlying system calls (like `poll' and `select').  Differences
between interpreters add another dimension of complexity to this.

> I believe that operation is asynchronous with certain targets,
> although I have never managed to create these conditions, even with
> gdbserver over TCP.

Actually, I think that the asynchronous operation is independent of
the target.  The infrastructure for this is in event-loop.c, which is
not specific to any target.

The problem with implementing async operation with the CLI interface
is, AFAIU, not its dependence on some target-specific feature, but
rather the need to redesig the CLI front end to do something useful
while waiting for a prolonged operation to run to completion.  For GUI
front ends, such as those who use MI, it's clear what to do during
that time, and the separate-process implementation makes it even
easier to design.  By contrast, the CLI interface is part of the GDB
process.

I don't consider myself a specialist in these matters, so please take
the above with a grain of salt (i.e., it might all be wrong ;-).

Re: MI output command error

[Nick Roberts]

 > > ... However, given that MI was introduced in GDB 5.0, I think there
 > > should be something in the manual explaining this as it seems to create a
 > > lot of confusion. It needs to be written by someone who understands the
 > > issue i.e not myself.
 > 
 > I'm all for documenting this in some useful way, but I fail to see how
 > could this be done.  Describing the async operation itself is already
 > a big challenge, as the details are extremely confusing, unless you've
 > read the code several times and have a good understanding of the
 > underlying system calls (like `poll' and `select').  Differences
 > between interpreters add another dimension of complexity to this.

Well for someone to be able to code it must mean that it can be documented.
But if you mean that those who did the coding are no longer available to
do the documenting, then I can see this would be a difficult task.

 > > I believe that operation is asynchronous with certain targets,
 > > although I have never managed to create these conditions, even with
 > > gdbserver over TCP.
 >
 > Actually, I think that the asynchronous operation is independent of
 > the target.  The infrastructure for this is in event-loop.c, which is
 > not specific to any target.

With gdbserver over TCP, on the host machine you can use e.g

1) target async localhost:1234

instead of

2) target remote localhost:1234

and GDB behaves slightly differently

Using CLI, "cont &" gives:

Asynchronous execution not supported on this target.

with 2) and

Continuing.

with 1).

However the inferior doesn't actually seem to continue execution as it
normally would and issuing a further command (that need not be about
the state of execution gives someting like:

(gdb) info target
Cannot execute this command while the target is running.

Using MI:

-target-select remote localhost:1234
^connected,thread-id="0",frame={addr="0x400012e0",func="??",args=[]}
(gdb) 
111-exec-continue
111^running
(gdb) 
-exec-interrupt

The MI command -exec-interrupt does not reach GDB

-target-select async localhost:1234
^connected,thread-id="0",frame={addr="0x400012e0",func="??",args=[]}
(gdb) 
111-exec-continue
111^running
(gdb) 
-exec-interrupt
^done
(gdb) 
-exec-continue
^error,msg="Cannot execute command exec-continue while target running"
(gdb) 

The MI command -exec-interrupt is acknowledged but again the inferior doesn't
actually seem to continue execution and GDB seems to think the target is still
running

So it look like the asynchronous operation has been partially implemented.

 > The problem with implementing async operation with the CLI interface
 > is, AFAIU, not its dependence on some target-specific feature, but
 > rather the need to redesig the CLI front end to do something useful
 > while waiting for a prolonged operation to run to completion.  For GUI
 > front ends, such as those who use MI, it's clear what to do during
 > that time, and the separate-process implementation makes it even
 > easier to design.  By contrast, the CLI interface is part of the GDB
 > process.

Actually if the asynchronous operation was working, I'm not sure what I would
do with it. When I debug, I'm used to waiting for execution to stop. The only
exception that I can think of is the Etnus debugger, where you can press a key
to get a snapshot of the stack during execution.

 > I don't consider myself a specialist in these matters, so please take
 > the above with a grain of salt (i.e., it might all be wrong ;-).

You know more than I do, and I appreciate you sharing it.

Nick

Re: MI output command error

[Daniel Jacobowitz]

On Sun, Mar 13, 2005 at 10:35:02PM +1300, Nick Roberts wrote:
> Using MI:
> 
> -target-select remote localhost:1234
> ^connected,thread-id="0",frame={addr="0x400012e0",func="??",args=[]}
> (gdb) 
> 111-exec-continue
> 111^running
> (gdb) 
> -exec-interrupt
> 
> The MI command -exec-interrupt does not reach GDB
> 
> -target-select async localhost:1234
> ^connected,thread-id="0",frame={addr="0x400012e0",func="??",args=[]}
> (gdb) 
> 111-exec-continue
> 111^running
> (gdb) 
> -exec-interrupt
> ^done
> (gdb) 
> -exec-continue
> ^error,msg="Cannot execute command exec-continue while target running"
> (gdb) 
> 
> The MI command -exec-interrupt is acknowledged but again the inferior doesn't
> actually seem to continue execution and GDB seems to think the target is still
> running
> 
> So it look like the asynchronous operation has been partially implemented.

Are you interested in debugging this problem?  If you are, I will
volunteer to add tests for it to the testsuite on platforms which
support gdbserver.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI output command error

[Nick Roberts]

 > > Using MI:
 > > 
 > > -target-select remote localhost:1234
 > > ^connected,thread-id="0",frame={addr="0x400012e0",func="??",args=[]}
 > > (gdb) 
 > > 111-exec-continue
 > > 111^running
 > > (gdb) 
 > > -exec-interrupt
 > > 
 > > The MI command -exec-interrupt does not reach GDB
 > > 
 > > -target-select async localhost:1234
 > > ^connected,thread-id="0",frame={addr="0x400012e0",func="??",args=[]}
 > > (gdb) 
 > > 111-exec-continue
 > > 111^running
 > > (gdb) 
 > > -exec-interrupt
 > > ^done
 > > (gdb) 
 > > -exec-continue
 > > ^error,msg="Cannot execute command exec-continue while target running"
 > > (gdb) 
 > > 
 > > The MI command -exec-interrupt is acknowledged but again the inferior doesn't
 > > actually seem to continue execution and GDB seems to think the target is still
 > > running
 > > 
 > > So it look like the asynchronous operation has been partially implemented.
 > 
 > Are you interested in debugging this problem?  If you are, I will
 > volunteer to add tests for it to the testsuite on platforms which
 > support gdbserver.

At the moment I have some time, so I can offer to try. I will need some hand
holding though. What files should I look at, and what behaviour would you expect?


Nick

Re: MI output command error

[Daniel Jacobowitz]

On Mon, Mar 14, 2005 at 09:14:13AM +1300, Nick Roberts wrote:
>  > > Using MI:
>  > > 
>  > > -target-select remote localhost:1234
>  > > ^connected,thread-id="0",frame={addr="0x400012e0",func="??",args=[]}
>  > > (gdb) 
>  > > 111-exec-continue
>  > > 111^running
>  > > (gdb) 
>  > > -exec-interrupt
>  > > 
>  > > The MI command -exec-interrupt does not reach GDB
>  > > 
>  > > -target-select async localhost:1234
>  > > ^connected,thread-id="0",frame={addr="0x400012e0",func="??",args=[]}
>  > > (gdb) 
>  > > 111-exec-continue
>  > > 111^running
>  > > (gdb) 
>  > > -exec-interrupt
>  > > ^done
>  > > (gdb) 
>  > > -exec-continue
>  > > ^error,msg="Cannot execute command exec-continue while target running"
>  > > (gdb) 
>  > > 
>  > > The MI command -exec-interrupt is acknowledged but again the inferior doesn't
>  > > actually seem to continue execution and GDB seems to think the target is still
>  > > running
>  > > 
>  > > So it look like the asynchronous operation has been partially implemented.
>  > 
>  > Are you interested in debugging this problem?  If you are, I will
>  > volunteer to add tests for it to the testsuite on platforms which
>  > support gdbserver.
> 
> At the moment I have some time, so I can offer to try. I will need some hand
> holding though. What files should I look at, and what behaviour would you expect?

Have I mentioned that I don't know anything about MI? :-)  I'm afraid I
have no advice.  I would expect -exec-interrupt to send a signal to the
target process, just like GDB's SIGINT handler does.  Which isn't
perfect, but generally works.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI output command error

[Nick Roberts]

 > > At the moment I have some time, so I can offer to try. I will need some
 > > hand holding though. What files should I look at, and what behaviour
 > > would you expect?
 > 
 > Have I mentioned that I don't know anything about MI? :-)  I'm afraid I
 > have no advice.  I would expect -exec-interrupt to send a signal to the
 > target process, just like GDB's SIGINT handler does.  Which isn't
 > perfect, but generally works.

OK. Theres an example in the manual that I can follow:

     (gdb)
     111-exec-continue
     111^running
     
     (gdb)
     222-exec-interrupt
     222^done
     (gdb)
     111*stopped,signal-name="SIGINT",signal-meaning="Interrupt",
     frame={addr="0x00010140",func="foo",args=[],file="try.c",line="13"}
     (gdb)

However, with it looking like Andrew has gone AWOL, who would review any such
patches?

Nick

Re: MI output command error

[Daniel Jacobowitz]

On Mon, Mar 14, 2005 at 12:32:18PM +1300, Nick Roberts wrote:
>  > > At the moment I have some time, so I can offer to try. I will need some
>  > > hand holding though. What files should I look at, and what behaviour
>  > > would you expect?
>  > 
>  > Have I mentioned that I don't know anything about MI? :-)  I'm afraid I
>  > have no advice.  I would expect -exec-interrupt to send a signal to the
>  > target process, just like GDB's SIGINT handler does.  Which isn't
>  > perfect, but generally works.
> 
> OK. Theres an example in the manual that I can follow:
> 
>      (gdb)
>      111-exec-continue
>      111^running
>      
>      (gdb)
>      222-exec-interrupt
>      222^done
>      (gdb)
>      111*stopped,signal-name="SIGINT",signal-meaning="Interrupt",
>      frame={addr="0x00010140",func="foo",args=[],file="try.c",line="13"}
>      (gdb)
> 
> However, with it looking like Andrew has gone AWOL, who would review any such
> patches?

Please, let's discuss that after we have patches to review... I can
review patches for technical merit, as can the other GDB maintainers,
and I don't think Andrew is "AWOL".  Maintainers are allowed to have
lives of their own, you know :-) I'm sure he will be active again soon,
or if (unlikely) not, we can seek new MI maintainers once we find out
where he went.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI output command error

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 13 Mar 2005 22:35:02 +1300
> Cc: drow@false.org, dave.korn@artimi.com, kostik@ispras.ru,
> 	gdb@sources.redhat.com
> 
>  > I'm all for documenting this in some useful way, but I fail to see how
>  > could this be done.  Describing the async operation itself is already
>  > a big challenge, as the details are extremely confusing, unless you've
>  > read the code several times and have a good understanding of the
>  > underlying system calls (like `poll' and `select').  Differences
>  > between interpreters add another dimension of complexity to this.
> 
> Well for someone to be able to code it must mean that it can be documented.
> But if you mean that those who did the coding are no longer available to
> do the documenting, then I can see this would be a difficult task.

People who code are generally never available for documenting (present
company excluded), that's why gdbint.texinfo is in such poor shape ;-)

But what I meant was that, knowing what I do about the event loop, I
don't know how to document it in a useful way, because talking about
async operation is generally hard.  Of course, I will applaud anyone
who tries, and will try to help such an effort ion any way I can.

> Actually if the asynchronous operation was working, I'm not sure what I would
> do with it. When I debug, I'm used to waiting for execution to stop.

Precisely.  That is one reason why async CLI operation was never fully
implemented: the event loop is ready for it, but the CLI layer simply
waits until some event comes in.

Re: MI output command error

[Peter D HUERTER]

Eli Zaretskii wrote:

>>From: Nick Roberts <nickrob@snap.net.nz>
>>Date: Sun, 13 Mar 2005 22:35:02 +1300
>>Cc: drow@false.org, dave.korn@artimi.com, kostik@ispras.ru,
>>	gdb@sources.redhat.com
>>
>> > I'm all for documenting this in some useful way, but I fail to see how
>> > could this be done.  Describing the async operation itself is already
>> > a big challenge, as the details are extremely confusing, unless you've
>> > read the code several times and have a good understanding of the
>> > underlying system calls (like `poll' and `select').  Differences
>> > between interpreters add another dimension of complexity to this.
>>
>>Well for someone to be able to code it must mean that it can be documented.
>>But if you mean that those who did the coding are no longer available to
>>do the documenting, then I can see this would be a difficult task.
>>    
>>
>
>People who code are generally never available for documenting (present
>company excluded), that's why gdbint.texinfo is in such poor shape ;-)
>
>But what I meant was that, knowing what I do about the event loop, I
>don't know how to document it in a useful way, because talking about
>async operation is generally hard.  Of course, I will applaud anyone
>who tries, and will try to help such an effort ion any way I can.
>
>  
>
>>Actually if the asynchronous operation was working, I'm not sure what I would
>>do with it. When I debug, I'm used to waiting for execution to stop.
>>    
>>
>
>Precisely.  That is one reason why async CLI operation was never fully
>implemented: the event loop is ready for it, but the CLI layer simply
>waits until some event comes in.
>  
>
Asynchronous mode allows for a "halt" command to be used to stop a 
program (instead of ^C for example).  This is important for debugging 
thread-parallel and process-parallel programs.  E.g. when debugging an 
MPI-CH program that runs into deadlock, using ^C is not an option 
because it kills the background listener processes which may not be 
under the control of the debugger.

In the context of parallel debugging, ptools.org describes asynchronous 
command mode.  The old HPDF (High Performance Debugging Forum) initiative.

Pete.

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