From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6325 invoked by alias); 30 May 2006 20:14:21 -0000 Received: (qmail 6311 invoked by uid 22791); 30 May 2006 20:14:20 -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; Tue, 30 May 2006 20:14:18 +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 k4UKEDij001761; Tue, 30 May 2006 13:14:13 -0700 (PDT) Received: from [17.201.22.244] (unknown [17.201.22.244]) by relay5.apple.com (Apple SCV relay) with ESMTP id A16FB324014; Tue, 30 May 2006 13:14:13 -0700 (PDT) In-Reply-To: <20060530185446.GF31100@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> <6FE49E5C-CD1C-45FC-B2FF-97E4B2FFA779@apple.com> <20060530185446.GF31100@brasko.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CF6F2BF-276F-4634-BA75-80698EEE64EE@apple.com> Cc: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI query questions Date: Tue, 30 May 2006 21:11: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/msg00404.txt.bz2 On May 30, 2006, at 11:54 AM, Bob Rossi wrote: > On Tue, May 30, 2006 at 11:40:51AM -0700, Jim Ingham wrote: >> 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. > > I undstand, and sort of agree with you. However, things get slightly > worse from my perspective. I've designed my FE thus far to behave like > this: > - It is always looking for data from GDB to assemble MI output > records. > - It will send only a single GDB command at a time. > > With that in mind, my FE assembles an MI output record, and then sends > it up the chain to be looked at more specifically. However, with this > callback-in-the-middle scenario, my FE will have to be retrained to > handle partially returned MI output records. > > Does this seem acceptable to you? > > For instance, the annotate=2 looks like this: > pre-prompt > (gdb) > prompt > b A::func > > post-prompt > [0] cancel > [1] all > [2] A::func(float) at overloaded.cpp:8 > [3] A::func(int) at overloaded.cpp:7 > > pre-overload-choice >> > overload-choice > > I think the overload choice is as much a prompt as any other > command. I'm > not exactly sure why you think it's a "special" input from the user. I thought Daniel already answered this. It's not prompting for MI input, which is what the ordinary prompt does, it's just trying to slide some information to the CLI interpreter under the covers. As such it is very different from the ordinary prompt. You also don't have a completed MI output at this point - you haven't seen the matching ^done or any other appropriate command terminator - so in any case you are going to have to deal with partial MI output. I also like this =read-one-line thingie, because it makes it explicit what's going on, namely something other than the MI is trying to read one line of input. So the FE should solicit a line of input from whoever it's getting that from in the command that caused this message to be delivered, and send it on... Jim > > I do see your point about the way your FE does this, however, do > you see > my point here? > > Thanks, > Bob Rossi