Re: MI: "^running" issues

[Eli Zaretskii <eliz@gnu.org>]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Thu, 6 Sep 2007 23:34:41 +0400
> Cc: gdb@sources.redhat.com
> 
> > > > A less trivial example is "info break" (to see 
> > > > what breakpoints were already hit during execution up to now, in case
> > > > your "commands" for the breakpoints continue the target).
> > > 
> > > Technically speaking, you don't need async for that -- you can interrupt
> > > the target, provide output, and then go on.
> > 
> > If the target is timing-sensitive, interrupting it is not a good idea,
> > as it can disrupt the timing and cause all kinds of side effects that
> > will ruin your debug session.
> 
> It appears to me that the time to interrupt the target, print output
> and resume is roughly equal to the time it takes to a hit of breakpoint
> with commands.

That's probably true, but consider this: when I put a breakpoint in
some place, I presumably know what I'm doing, and can plan my
breakpoints and the associated commands so that they don't disrupt the
program's operation.  By contrast, an interrupt at some random time
cannot be planned like that.

> And basically, I don't care much about existing code.

Well, I do, especially given the people who wrote it.

> What I'm concerned is that I have
> a real bug, where "^running" is not output where it should be.

If there is a bug, it should be fixed, there's no doubt about that.

> The code related to that bug has something to do with async mode,
> but it's pretty unclear why it should be, and how would I test
> that my fixes don't break that async mode.

Well, Nick is trying to improve on the async code, perhaps he could
help understand the offending code and find the right fix for the
problem you found.