This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |