Re: MI: "^running" issues

[Vladimir Prus <ghost@cs.msu.su>]

Jim Ingham wrote:

> We got the asynchronous mode working for the Mac OS X target in the
> Apple gdb sources.  It definitely took a bunch of work beyond what is
> in the current FSF sources to get all the details working (things like
> breakpoint commands that restart the target and command files and some
> other bits like that needed attending to...)  It wasn't deadly hard to
> do, though.
> 
> We use it mostly so that Xcode can query the target's state at any
> point - basically a backstop when it looks like maybe the UI and gdb
> have gotten out of sync.  That way you can always unambiguously get
> the tri-state answer - the target's stopped; the target's running;
> gdb's gone south.  This is actually pretty useful to have around,
> though in a perfect world would not be necessary...

I see. So, the problem is that in real world those "^running" and
"*stopped" are not necessary always output when needed, so you can
get out of sync?

> We also use -exec-interrupt.  It's certainly true that you can achieve
> the same thing by sending ^C to the target, but it's much more regular
> to do everything you're doing with the target through the same control
> channel.  And of course, this moves to gdb the knowledge of any
> funniness with interrupting a running program - which is where it
> belongs.

Hmm, if you send ^C to gdb, then gdb can handle interrupting the program
just fine.
 
> Another stronger reason why async was originally done was the
> experience of merging gdb with Tcl/Tk for the Insight debugger.  One
> of the big reasons for the instability of that project is that when
> the target is running, gdb is blocked, so if you want to service other
> events - like window system events in the case of Insight - you've got
> no good way to do that.  We ended up having to run a timer and try to
> service events in the timer interrupt - a dubious practice at best.
> 
> It's possible to run the interpreter in a separate thread, and let it
> and gdb communicate through some side channel.  But most interpreters
> have some mechanism for handling events, and it is much cleaner to
> have gdb be just another event source.

I presume this is only relevant when gdb is combined with some other
code in the same process? Last time I've asked about this, I was
told that it not supported, because gdb does fancy things with signals,
or something like that.

- Volodya