From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7544 invoked by alias); 29 May 2006 14:47:06 -0000 Received: (qmail 7531 invoked by uid 22791); 29 May 2006 14:47:04 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 29 May 2006 14:46:43 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fkj0z-0003DW-0O for gdb@sources.redhat.com; Mon, 29 May 2006 10:46:41 -0400 Date: Tue, 30 May 2006 08:20:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: MI query questions Message-ID: <20060529144640.GA12145@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20060529122337.GB2021@brasko.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060529122337.GB2021@brasko.net> User-Agent: Mutt/1.5.11+cvs20060403 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/msg00386.txt.bz2 On Mon, May 29, 2006 at 08:23:37AM -0400, Bob Rossi wrote: > The first small issue is that the '[1] all\n' choice is on the same > line as the [0] choice. That's because the ~"" blocks come from individual calls to printf. > The second issue is how GDB outputs a final ">" line. This isn't a valid > GDB/MI Output record/command. At least, I don't think it is. If I select > an option, then I get this > Which looks pretty good to me. So the problem is, the line ">" > apparently means to get input from the user. This isn't specified in the > MI OUTPUT record. Should we change the OUTPUT record to represent > interactive commands? I don't really think we should shoehorn these queries into MI. It would make more sense to me to have it do something MI-like. For example, not set any breakpoint, but return a more exact list of places the breakpoint could be placed. If you want the query behavior, you could of course use interpreter-exec :-) I dunno what that new response would look like, and I'm not especially interested in working it out; just sharing my opinion. The > bit is very un-MI, and e.g. it prevents pipelining MI commands. -- Daniel Jacobowitz CodeSourcery