From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22748 invoked by alias); 11 May 2006 17:03:12 -0000 Received: (qmail 22739 invoked by uid 22791); 11 May 2006 17:03:10 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao04.cox.net (HELO eastrmmtao04.cox.net) (68.230.240.35) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 May 2006 17:03:07 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao04.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060511170305.JRUB9931.eastrmmtao04.cox.net@localhost.localdomain>; Thu, 11 May 2006 13:03:05 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FeEZl-0002UA-Hs; Thu, 11 May 2006 13:03:45 -0400 Date: Thu, 11 May 2006 19:24:00 -0000 From: Bob Rossi To: Jim Ingham Cc: Alain Magloire , gdb@sources.redhat.com Subject: Re: asynchronous MI output commands Message-ID: <20060511170345.GB1600@brasko.net> Mail-Followup-To: Jim Ingham , Alain Magloire , gdb@sources.redhat.com References: <3518719F06577C4F85DA618E3C37AB9105359F5C@nimbus.ott.qnx.com> <20060511150249.GA1600@brasko.net> <02162C41-8C3C-49B8-99BB-3394075E305A@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02162C41-8C3C-49B8-99BB-3394075E305A@apple.com> User-Agent: Mutt/1.5.9i X-IsSubscribed: yes 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: 2006-05/txt/msg00150.txt.bz2 On Thu, May 11, 2006 at 08:42:03AM -0700, Jim Ingham wrote: > I think that the lack of notification about what has gone on when > somebody uses interpreter-exec to run the target is just a bug in the > interpreter-exec command. Since that command allows lots of stuff to > go on behind the MI client's back, you need to inform the client > about this. You could either post asynchronous notifications about > what happened (for instance an =running or whatever) or you can just > make the -interpreter-exec command behave like -exec-next when it > does indeed run the target. The latter is what we did for Xcode, so > you get the *stopped message if the target was run. Hi Jim, Well, I agree that this is a bug in the interpreter-exec command. I think both of your solution are appropriate. I would find it interesting to know which solution is easier to implement in GDB. The interesting case of course is when the user does a single CLI command that is a 'commands' definition. Thus, a single -interpreter-exec command can be similar to running N CLI commands. I haven't even tested this case out yet, but I'm assuming there's big problems in this area. I seem to have more time lately, and would like to start patching up some of these holes. I would very much like to see mi3 come out soon, with a lot of these problems resolved. Thanks, Bob Rossi