From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31669 invoked by alias); 15 Aug 2005 04:26:53 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31577 invoked by uid 22791); 15 Aug 2005 04:26:47 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 15 Aug 2005 04:26:47 +0000 Received: from farnswood.snap.net.nz (p20-tnt1.snap.net.nz [202.124.110.20]) by viper.snap.net.nz (Postfix) with ESMTP id B25CB688D41; Mon, 15 Aug 2005 16:26:43 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 2DDFD62A99; Mon, 15 Aug 2005 05:28:07 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17152.6615.577337.131388@farnswood.snap.net.nz> Date: Mon, 15 Aug 2005 10:03:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution In-Reply-To: <20050815021546.GA20931@nevyn.them.org> References: <17151.52148.262754.334426@farnswood.snap.net.nz> <20050815021546.GA20931@nevyn.them.org> X-SW-Source: 2005-08/txt/msg00172.txt.bz2 > > Using strcmp (interpreter_p, "mi") and not strncmp (interpreter_p, "mi", 2) > > means that this should only change behaviour for the current mi level. > > Checking the name of the MI interpreter seems inelegant. It'll break > this when we transition from MI2 to MI3 as the stable version for > instance. Maybe there's a way to make mi_version usable outside of > mi/*. If the change proves to a good one (which seems unlikely now) then it could possibly be used for all versions. > Forcing this to raw_stdout is also not OK, since my whole point was to > pass this information to the interpreter so that it can distribute it > to clients appropriately - they may not be on stdout. I realize that's > what the MI layer previously did, but I don't get a good taste in my > mouth from bypassing the MI output layer this way. You presumably mean what the MI layer _currently does_. Using raw_stdout doesn't improve things but it doesn't make them any worse. > The hooks we were talking about were primarily for things like the > breakpoint list and thread list. The ^running response is touchier. > ^running is a result record, not an async record. It has to be the > result of a command. It is classed as a result record in MI but presumably its an asynchronous process. Perhaps it should be *running, just as it is *stopped. Treating it as a result record means that new commands which run the inferior must also call mi_execute_async_cli_command or they won't output ^running. Putting it in proceed ensures this automatically. > Bob's our expert on this, but I'd think that this > change could break the grammar. There's probably a way to get this to > happen when the resulting prompt does not signify that another command > may be accepted now. > > Certainly it makes verifying from the source that we obey the grammar > much more difficult, by moving bits of the MI implementation into > infrun. That's enough reason for it not to have been done this way in > the first place - it's harder to maintain. I will look at making to more modular. You have said: DJ> What I'd like to see is a way to keep multiple interpreters open at the DJ> same time.Then, have one of them accepting input at a time, and receiving DJ> informative output, but all of them receiving some kinds of output. This presumably requires the code that generates MI output to be moved outside MI specific code. > Also, Bob said he was willing to work on doing this correctly. I'm lost. I'm not sure what correctly means in this case. I would like to get MI-like output (specifically about whether the execution is running or not) from CLI commands. Is Bob offering to do this? Nick