This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: MI output during program execution
On Tue, Aug 09, 2005 at 08:41:28PM -0400, Daniel Jacobowitz wrote:
> On Tue, Aug 09, 2005 at 06:34:21PM -0400, Bob Rossi wrote:
> > However, in the meantime, I think it's possible to query the state of
> > GDB at any moment. So, if you allow the user to enter a command via
> > -interpreter-exec console, you could then follow that command up with
> > other MI commands to sync the state of GDB with the state of the FE.
>
> But we haven't got all the relevant query commands, I think. And I
> haven't a clue what the full set would be. Rather than adding them,
> investing effort in getting the async approach going makes more sense
> to me.
I agree. However, getting the observer approach up and running, will in
a way, define the full set.
> As Jim's pointed out, you can need this any time you hit a breakpoint,
> if the user has set commands on it. Keeping track of this in the FE is
> going to be tricky. Also, if you're presenting a real console window
> and you have to do a half-dozen queries after every command to keep the
> UI up to date, that's probably going to be visibly slow.
Here is another odd scenario, Jim, please give some info if you have
experience in this area.
If you hit a breakpoint, and the observer starts to send you data, does
it
- send all the state data in one async response, in the same response as
the async MI command that says *stopped?
- send all the state data in one async response, in a different response
as the async MI command that says *stopped?
- send all the state data, each in different async response's, in a
different response as the async MI command that says *stopped?
This may seem unimportant, however I believe it could be marginally
important. For instance, does the front end have to wait for the async
observer response before it can do anything else?
Thanks,
Bob Rossi