From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22034 invoked by alias); 6 Sep 2007 11:39:18 -0000 Received: (qmail 22026 invoked by uid 22791); 6 Sep 2007 11:39:18 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao104.cox.net (HELO eastrmmtao104.cox.net) (68.230.240.46) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Sep 2007 11:39:06 +0000 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070906113904.FWPN22245.eastrmmtao104.cox.net@eastrmimpo01.cox.net>; Thu, 6 Sep 2007 07:39:04 -0400 Received: from black ([70.181.32.198]) by eastrmimpo01.cox.net with bizsmtp id kzf41X0054GV2Jm0000000; Thu, 06 Sep 2007 07:39:04 -0400 Received: from bob by black with local (Exim 4.63) (envelope-from ) id 1ITFhP-0005Gm-RE; Thu, 06 Sep 2007 07:39:03 -0400 Date: Thu, 06 Sep 2007 14:38:00 -0000 From: Bob Rossi To: Vladimir Prus Cc: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: MI: "^running" issues Message-ID: <20070906113903.GH5805@cox.net> Mail-Followup-To: Vladimir Prus , Eli Zaretskii , gdb@sources.redhat.com References: <200709041653.22357.ghost@cs.msu.su> <200709061046.21723.ghost@cs.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709061046.21723.ghost@cs.msu.su> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00049.txt.bz2 On Thu, Sep 06, 2007 at 10:46:21AM +0400, Vladimir Prus wrote: > On Thursday 06 September 2007 07:19:11 Eli Zaretskii wrote: > > > From: Vladimir Prus > > > Date: Wed, 05 Sep 2007 22:41:38 +0400 > > A less trivial example is "info break" (to see > > what breakpoints were already hit during execution up to now, in case > > your "commands" for the breakpoints continue the target). > > Technically speaking, you don't need async for that -- you can interrupt > the target, provide output, and then go on. Making this async will maybe > cut some fraction of section from the run time, why do we care? This isn't necessarily true. It is not guarenteed that you will be able to interupt the target. I'm pretty sure this won't always work with cygwin. > > Note that I'm not actually saying these commands will work > > asynchronously in the current GDB, as the implementation of async > > execution was never finished, AFAIK. > > > > > and are those commands of big enough value to user to warrant > > > extensive coding? One example of a command that would be really useful would be -exec-interupt. I've discussed this extensively in the past. Sending a ^c to the inferior is not the perfect way to stop the inferior from running. That's because typically a front end will put the inferior on a tty to separate the output of the inferior from the output of gdb/mi. As soon as this is done, it becomes unclear if the ^c should be sent to the gdb/mi tty or the inferior stdin tty. Again, this is especially true on windows. > > > Can interested parties document those commands at GDB Wiki, or even > > > in email? > > > > The list depends on what we decide to code, so I don't think anyone > > can publish it now. > > I think at least some design should be present before coding, so it would > be reasonable that anybody who submits some async patches be ready to > explain the final goal -- what commands will be async, will it be just async, > or multithreaded, and what will be essential benefits for CLI user and for > frontends. > > The way it stands now is more like "let's develop async mode, and then see > what commands we can run in async mode, and then see what benefit that > will have". Yeah, in general, I think this is how the MI stuff is developed though. There doesn't seem to be anyone with a clear vision dedicated to gdb/mi. It's unfortunate. I mean, each front end developer of gdb/mi eventually becomes a gdb/mi developer. It's pretty sad. Bob Rossi