From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12093 invoked by alias); 11 May 2006 17:35:27 -0000 Received: (qmail 12085 invoked by uid 22791); 11 May 2006 17:35:26 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 May 2006 17:35:24 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k4BHZIKe013933; Thu, 11 May 2006 10:35:18 -0700 (PDT) Received: from [17.201.22.240] (unknown [17.201.22.240]) by relay5.apple.com (Apple SCV relay) with ESMTP id D171C324013; Thu, 11 May 2006 10:35:17 -0700 (PDT) In-Reply-To: <20060511170345.GB1600@brasko.net> References: <3518719F06577C4F85DA618E3C37AB9105359F5C@nimbus.ott.qnx.com> <20060511150249.GA1600@brasko.net> <02162C41-8C3C-49B8-99BB-3394075E305A@apple.com> <20060511170345.GB1600@brasko.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5671FFE9-AC72-4100-B0A6-38E944074C68@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 19:25: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/msg00151.txt.bz2 On May 11, 2006, at 10:03 AM, Bob Rossi wrote: > 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. We seem to get it half right for defined commands. For instance: (gdb) list main 1 int main (int argc, char **argv) 2 { 3 4 printf ("I got %d arguments\n", argc); 5 6 return 0; 7 } (gdb) break 4 Breakpoint 1 at 0x2cdc: file main.c, line 4. (gdb) break 6 Breakpoint 2 at 0x2cec: file main.c, line 6. (gdb) define printAndContinue Type commands for definition of "printandcontinue". End with a line saying just "end". >print argc >continue >end (gdb) run Starting program: /private/tmp/a.out Reading symbols for shared libraries . done Breakpoint 1, main (argc=1, argv=0xbffff404) at main.c:4 4 printf ("I got %d arguments\n", argc); (gdb) set interpreter mi -interpreter-exec console-quoted printAndContinue ~"$1 = 1" ~"\n" ^continuing I got 1 arguments ~"\nBreakpoint " ~"2, main (argc=1, argv=0xbffff404) at main.c:6\n" ~"6\t return 0;\n" ^done,MI_HOOK_RESULT= {HOOK_TYPE="frame_changed",frame="0"},MI_HOOK_RESULT= {HOOK_TYPE="stack_changed"} Normally the "I got 1 arguments" line would go to the tty for the target, so that wouldn't show up in the output that the MI client would be parsing. What we do here is emit the "^continuing" so the MI can know that the target started. This might more properly be an "=running" or something like that. I think this is just an artifact of how the mi works right now. Then when the defined command stops, we tell the MI what has changed in these HOOK_RESULT output messages. Again, it's arguable that these should also be "=" type messages. When I started working on this Xcode (ProjectBuilder as it then was) was not good at handling the "=" type asynchronous messages, and I haven't gotten around to changing this. You don't get a *stopped message because the continuation is buried in the defined command. We could fix this, and if the target has run tell the client that it has indeed stopped. But this may also be an argument that it's better to tell the client about this through the asynchronous "=" messages, especially since the define command could run a number of times, and end up with a command that doesn't run the target. Anyway, what we have now works well enough, if a little irregular, and I don't think fixing it up to be nicer looking would be particularly hard to do. Note that breakpoint commands can also be a problem here, since they can run console commands out from under the MI. They can in fact cause the target to stop, print some stuff, then continue again. So if you allow this - which we had a lot of pressure to do since breakpoint commands are pretty handy - you have to do a little fiddling to get that right as well. Jim > > 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