From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15862 invoked by alias); 6 Sep 2007 18:08:09 -0000 Received: (qmail 15755 invoked by uid 22791); 6 Sep 2007 18:08:08 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Sep 2007 18:08:03 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ITLlj-0002Gq-QB for gdb@sources.redhat.com; Thu, 06 Sep 2007 20:07:55 +0200 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Sep 2007 20:07:55 +0200 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Sep 2007 20:07:55 +0200 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: MI: "^running" issues Date: Thu, 06 Sep 2007 18:34:00 -0000 Message-ID: References: <200709041653.22357.ghost@cs.msu.su> <18142.15716.179444.106490@kahikatea.snap.net.nz> <200709050938.45290.ghost@cs.msu.su> <9B94A61F-90AD-426F-BD4D-B8ED6B9A5AF4@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.4 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00054.txt.bz2 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