From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32435 invoked by alias); 11 May 2006 15:42:12 -0000 Received: (qmail 32426 invoked by uid 22791); 11 May 2006 15:42:12 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 May 2006 15:42:09 +0000 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k4BFg4SQ023479; Thu, 11 May 2006 08:42:04 -0700 (PDT) Received: from [17.201.22.240] (unknown [17.201.22.240]) by relay8.apple.com (Apple SCV relay) with ESMTP id 591A2707; Thu, 11 May 2006 08:42:04 -0700 (PDT) In-Reply-To: <20060511150249.GA1600@brasko.net> References: <3518719F06577C4F85DA618E3C37AB9105359F5C@nimbus.ott.qnx.com> <20060511150249.GA1600@brasko.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02162C41-8C3C-49B8-99BB-3394075E305A@apple.com> Cc: Alain Magloire , gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: asynchronous MI output commands Date: Thu, 11 May 2006 16:40:00 -0000 To: Bob Rossi X-Mailer: Apple Mail (2.749.3) 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/msg00147.txt.bz2 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. Jim On May 11, 2006, at 8:02 AM, Bob Rossi wrote: >>>> I agree, the example that comes to my mind is "next", "step", >>>> "finish", >>>> "continue" etc ... To do some optimization front-ends will >>>> probably >>> need to >>>> know the last command issue (for example clearing all the >>>> variable state >>> in >>>> a variable view for "continue"). >>> >>> I see the point, however, how do you know if the user typed >>> continue? I >>> allow the user to have access to the console, and by doing so, I >>> can't >>> make any assumptions on what GDB is doing. >>> >> >> I suppose you could intercept the CLI commands before sending it >> to GDB > > This isn't a good idea, and probably impossible. Don't forget about > user > defined commands. Also, don't forget that hitting a breakpoint can run > some commands. You never really know when 'continue' is sent. >