Re: MI output command error

[Nick Roberts <nickrob at snap dot net dot nz>]

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