This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: linux native async mode support
On Saturday 05 April 2008 13:10:53 Nick Roberts wrote:
> > > The helper functions that you have written for common sequences are a good
> > > idea as they need only be updated in one place but the three here are the
> > > only ones of their kind (they output an extra "^done" over MI commands like
> > > -exec-next). Not really worth a dedicated helper function do you agree?
> >
> > Why there's extra "^done"? Presently, each command is supposed to have
> > either "^running" or "^done", not both.
>
> There's an extra "^done" because this is a CLI command entered in MI (and
> therfore case CLI_COMMAND: of captured_mi_execute_command). There are many
> issues here like should we diallow immediate use of CLI commands now and
> require explicit use of "-interpreter-exec console"?
Probably not -- I don't see any immediate advantage from that.
> Then "-interpreter-exec
> console next" doesn't emit "(gdb)/n" after "^running" when in asynchronous
> mode, so should we remove it from synchronous mode too (as you have suggested)?
This prompting is fairly confusing, so it could be that I've confused myself
as well, but I think "-interpreter-exec console next" actually *should* print
the prompt if the target is async-capable. The reason is that for MI mode,
we don't really care about terminal ownership issues, and then should not
care about sync_execution, and then this bit of code:
else if (sync_execution)
{
/* Don't print the prompt. We are executing the target in
synchronous mode. */
args->action = EXECUTE_COMMAND_SUPPRESS_PROMPT;
return;
}
in captured_mi_execute_command should be removed. In fact, I have a patch-in-progress
to do exactly that, and hopefully will be posting it later today.
> But these are all MI issues and this test is meant to just be a mark in the
> sand for asynchronous mode, and one that I had lying around. For the moment, I
> don't really want to work on it further
Okay :-) Then, will you mind if I apply this patch either when I'm done with
another round of MI testsuite cleanups I'm doing today, or after the ^done is gone,
whichever proves more convenient?
> > BTW, I'm not even sure that "^done" vs. "^running" + "^done" is so big
> > difference that a helper function cannot be introduced.
>
> The comment suggests that mi_gdb_test will not work but I have not revisited
> that since writing the test 18 months or so ago. If true, that could also
> make helper functions difficult.
Do you happen to remember what race condition the comment mentions?
- Volodya