Re: RFC: MI output during program execution

Nick Roberts
2005-08-15T04:26:53Z

> > Using strcmp (interpreter_p, "mi") and not strncmp (interpreter_p, "mi", 2)
> > means that this should only change behaviour for the current mi level.
>
> Checking the name of the MI interpreter seems inelegant. It'll break
> this when we transition from MI2 to MI3 as the stable version for
> instance. Maybe there's a way to make mi_version usable outside of
> mi/*.

If the change proves to a good one (which seems unlikely now) then it could
possibly be used for all versions.

> Forcing this to raw_stdout is also not OK, since my whole point was to
> pass this information to the interpreter so that it can distribute it
> to clients appropriately - they may not be on stdout. I realize that's
> what the MI layer previously did, but I don't get a good taste in my
> mouth from bypassing the MI output layer this way.

You presumably mean what the MI layer _currently does_. Using raw_stdout
doesn't improve things but it doesn't make them any worse.

> The hooks we were talking about were primarily for things like the
> breakpoint list and thread list. The ^running response is touchier.
> ^running is a result record, not an async record. It has to be the
> result of a command.

It is classed as a result record in MI but presumably its an asynchronous
process. Perhaps it should be *running, just as it is *stopped. Treating it
as a result record means that new commands which run the inferior must
also call mi_execute_async_cli_command or they won't output ^running. Putting
it in proceed ensures this automatically.

> Bob's our expert on this, but I'd think that this
> change could break the grammar. There's probably a way to get this to
> happen when the resulting prompt does not signify that another command
> may be accepted now.
>
> Certainly it makes verifying from the source that we obey the grammar
> much more difficult, by moving bits of the MI implementation into
> infrun. That's enough reason for it not to have been done this way in
> the first place - it's harder to maintain.

I will look at making to more modular. You have said:

DJ> What I'd like to see is a way to keep multiple interpreters open at the
DJ> same time.Then, have one of them accepting input at a time, and receiving
DJ> informative output, but all of them receiving some kinds of output.

This presumably requires the code that generates MI output to be moved
outside MI specific code.

> Also, Bob said he was willing to work on doing this correctly.

I'm lost. I'm not sure what correctly means in this case. I would like
to get MI-like output (specifically about whether the execution is running
or not) from CLI commands. Is Bob offering to do this?

Nick