Re: MI output command error

[Karganov Konstantin <kostik@ispras.ru>]

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