Re: MI output command error

Karganov Konstantin
2005-03-10T13:43:33Z

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