linux native async mode support

[Nick Roberts]

 > > 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"?  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)?

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
 
 >                                       I realize that fixing this requires
 > introducing "*running", so that we still know that the target is resumed.
 > I have the patch for *running basically done, so I suggest that I submit it,
 > and then we'll have just ^done in this example.

I'm not sure what the output will look like after your change but it may
still not be like normal MI output.

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

-- 
Nick                                           http://www.inet.net.nz/~nickrob