This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI/RFC] Emit ^running via observer.
On Saturday 28 June 2008 04:14:27 Nick Roberts wrote:
> > > mi-async.exp is a test for async mode, so is not expected to pass in sync
> > > mode.
> >
> > That's the question -- what about this test is specific to async mode?
>
> Async mode decouples the output from the input. This allows a CLI command that
> executes the inferior to (indirectly) generate MI output. That's why I was
> interested in async mode and that's what this test is for. The work has
> actually been done for more general reasons, such as non-stop mode. I think
> the MI output is just a fortunate side-effect.
Err, async mode does one thing -- allows commands to be processed while inferiour
is still running. Unless you explicitly make use of this functionality, there's
no difference from sync mode. (Of course, there's a bunch of checks for
target_can_async_p in GDB code, so some difference in output is possible, but
in theory there should be none). I don't know what you mean by decoupling output
from the input -- for example, then *running notification is emitted for CLI
just fine, and this does not require async mode.
> >...
> > > It's not a problem if async mode becomes the default, which is my
> > > understanding.
> >
> > Not mine, unfortunately. We can't even make all target always have at least
> > one element in thread list -- which is much simpler change.
>
> Maybe that's a requirement of non-stop mode but I'm not sure that this is
> relevant here, i.e. with just async mode.
I meant relative complexity of things. Making the thread list always have a single thread
is relatively straight-forward, but still, making this happen for
*all* targets is going to take lots of time. Adding async support for a target
is considerably harder -- as linux-nat.c changes clearly demonstrate. Therefore,
I don't expect that GDB will support async on a wide set of targets anytime soon.
- Volodya