Re[2]: MI output command error

[Konstantin Karganov <kostik at ispras dot ru>]

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