From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32765 invoked by alias); 22 Nov 2005 13:49:29 -0000 Received: (qmail 32757 invoked by uid 22791); 22 Nov 2005 13:49:29 -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; Tue, 22 Nov 2005 13:49:28 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1EeYWS-0001w9-6Q for gdb@sources.redhat.com; Tue, 22 Nov 2005 16:49:25 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1EeYWS-0001vv-4h for gdb@sources.redhat.com; Tue, 22 Nov 2005 16:49:24 +0300 From: Vladimir Prus To: gdb@sources.redhat.com Subject: Re: MI: asynchronous operation details Date: Tue, 22 Nov 2005 13:49:00 -0000 User-Agent: KMail/1.7.2 References: <200511221520.24163.ghost@cs.msu.su> <20051122133831.GA21354@white> In-Reply-To: <20051122133831.GA21354@white> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511221649.23598.ghost@cs.msu.su> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00479.txt.bz2 On Tuesday 22 November 2005 16:38, Bob Rossi wrote: > > > This is a feature that does not currently work. However, it's possible > > > that Nick Roberts work will address some of this lack of functionality. > > > If not, I'm sure in the future, either I (you) or someone else will > > > eventually get this working. > > > > Ok, but -- why do I ever want to issue commands while inferior is > > running? For which kind of commands is that useful? > > You could interupt the inferior, to tell it to stop. I think that would > be equivalent to typing ^c at the console now. Well, exactly. I can do "^C" today, so nothing gained at all. > Also, you could ask > GDB if it is currently busy, to determine if you can send another > command. That way, you wouldn't have to keep track of the state of GDB, > you could just always ask it what it's state is. That would be handy, but if there's "^running" packet in *all* cases where inferiour start running (e.g. when "run" is hidden inside user-defined command), then keeping track of state of GDB means just a single bool variable -- not much. And it GUI, you need to keep track of the state anyway, so that you can grey out some buttons. > I'm sure there are other useful features also. Still curious what are they ;-) - Volodya