From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6287 invoked by alias); 6 Sep 2007 18:41:14 -0000 Received: (qmail 6268 invoked by uid 22791); 6 Sep 2007 18:41:13 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Sep 2007 18:41:09 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1ITMHp-0000wT-Sc for gdb@sources.redhat.com; Thu, 06 Sep 2007 22:41:06 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1ITMHk-0000wD-QB; Thu, 06 Sep 2007 22:41:01 +0400 From: Vladimir Prus To: Jim Ingham Subject: Re: MI: "^running" issues Date: Thu, 06 Sep 2007 18:48:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb@sources.redhat.com References: <200709041653.22357.ghost@cs.msu.su> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709062241.01815.ghost@cs.msu.su> 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/msg00056.txt.bz2 On Thursday 06 September 2007 22:34:08 Jim Ingham wrote: > > On Sep 6, 2007, at 11:07 AM, Vladimir Prus wrote: > > > 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? > > Those are always bugs, and we fix them when we find them, but yes that > did happen - hasn't happened in a while though. What happens more > often now for us is that we rely a lot on calling functions to inspect > opaque data types when the target stops. This often goes bad - people > right data inspectors that can deadlock for instance... So it's > useful to have some "resync with gdb" action that check's gdb's state > and does the right thing based on what it is. You mean, calling functions in the program? Then, presumably if they hang, you get to interrupt their execution and somehow restore program context? Why do you need to know if inferior is running, in this case? As soon as you call a function in program, program is running ;-) > >> 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. > > Sure, but you're still using two ways to talk to gdb. Yes, MI and less nice ^C, over same pipe. I see how that's not ideal, but IMO is a minor issue. > > 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. > > Yes, this would be to support an in-process interpreter. But I don't > know about problems with signals. That part didn't cause Tcl any > difficulty, but that was a long time ago too. I don't know either, it's vague recollection. - Volodya