This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: "^running" issues
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