From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1221 invoked by alias); 30 May 2006 18:40:59 -0000 Received: (qmail 1211 invoked by uid 22791); 30 May 2006 18:40:59 -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; Tue, 30 May 2006 18:40:57 +0000 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k4UIeqIu019649; Tue, 30 May 2006 11:40:52 -0700 (PDT) Received: from [17.201.22.244] (unknown [17.201.22.244]) by relay8.apple.com (Apple SCV relay) with ESMTP id 6EFEF4E2; Tue, 30 May 2006 11:40:52 -0700 (PDT) In-Reply-To: <20060530181143.GE31100@brasko.net> References: <20060529122337.GB2021@brasko.net> <20060529144640.GA12145@nevyn.them.org> <20060530171518.GB31100@brasko.net> <7A4B9D88-47FB-4721-949F-632AF2E449FC@apple.com> <20060530175310.GD31100@brasko.net> <20060530181143.GE31100@brasko.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FE49E5C-CD1C-45FC-B2FF-97E4B2FFA779@apple.com> Cc: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI query questions Date: Tue, 30 May 2006 18:56: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/msg00401.txt.bz2 Seems like having a callback in your parser to handle async messages from gdb represents cleanly what is going on. You haven't gotten a completed MI command yet, and you're not ready for another MI command. But gdb is asking on the side for more input. Seems like making the two cases look the same is more likely to cause trouble. Jim On May 30, 2006, at 11:11 AM, Bob Rossi wrote: > On Tue, May 30, 2006 at 10:59:38AM -0700, Jim Ingham wrote: >> >> On May 30, 2006, at 10:53 AM, Bob Rossi wrote: >> >>> On Tue, May 30, 2006 at 10:48:53AM -0700, Jim Ingham wrote: >>>> Actually, to avoid confusion, this really looks like: >>>> >>>> (gdb) set interpreter mi1 >>>> -interpreter-exec console-quoted "break raise" >>>> ~"[0] cancel\n[1] all\n" >>>> ~"\nNon-debugging symbols:\n" >>>> ~"[2] -[NSException raise]\n" >>>> ~"[3] raise\n" >>>> =read-one-line,prompt="> " >>>> >>>> In our version of gdb the console interpreter really is the >>>> straight >>>> CLI console interpreter - this is required to get the "set >>>> interpreter" command to work. So we had to invent another >>>> interpreter that did the proper quoting. Anyway, this is what it >>>> would look like for you... >>> >>> This is also the solution I was thinking of. However, I would >>> like to >>> modify the MI OUTPUT record to show this as a possibility. Also, I >>> think >>> that this should be 1 full response. >>> (gdb) set interpreter mi1 >>> -interpreter-exec console-quoted "break raise" >>> ~"[0] cancel\n[1] all\n" >>> ~"\nNon-debugging symbols:\n" >>> ~"[2] -[NSException raise]\n" >>> ~"[3] raise\n" >>> =read-one-line,prompt="> " >>> (gdb) >>> >>> And then the user will send the command, and then get another full >>> response representing the breakpoint output. >>> >>> Does this make sense? >> >> I'm not sure I like this. It doesn't really seem to mirror what's >> going on. The -interpreter-exec command hasn't finished, rather, >> it's asking - out of band - for some more information. So sending an >> out-of-band message with this request seems cleaner. Why do you want >> the extra (gdb) prompt? >> >> Jim > > I'm not sure what I asked for makes the most sense. However, I don't > really like what I see above. > > Basically, up until now, the only time a front end would send data is > at the (gdb) prompt. That's when GDB is ready to except another > command. > This is also nice because if the FE generates a parser, it wants to > feed > that parser data until it spits out an MI output record. The parser > eventually spits out another MI outout record, the FE process's it, > and > then sends another command to GDB. > > However, in the case above, the parser will keep eating data, and then > at some point, GDB will stop sending data and the MI output record has > not been completed. This means the parser will have to have some ugly > callback mechanism saying that the FE should send another command > to GDB. > > What about something like this: > > (gdb) set interpreter mi1 > -interpreter-exec console-quoted "break raise" > ~"[0] cancel\n[1] all\n" > ~"\nNon-debugging symbols:\n" > ~"[2] -[NSException raise]\n" > ~"[3] raise\n" > =read-one-line,prompt="> " > (gdb_oob_query) > > I'm just brain storming here. What did you think of my rational? > > Bob Rossi