From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20371 invoked by alias); 8 May 2006 01:22:06 -0000 Received: (qmail 20360 invoked by uid 22791); 8 May 2006 01:22:05 -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, 08 May 2006 01:22:01 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FcuRj-0005vU-Ll; Sun, 07 May 2006 21:21:59 -0400 Date: Mon, 08 May 2006 01:52:00 -0000 From: Daniel Jacobowitz To: Bjarke Viksoe Cc: gdb@sourceware.org Subject: Re: asynchronous MI output commands Message-ID: <20060508012159.GA22622@nevyn.them.org> Mail-Followup-To: Bjarke Viksoe , gdb@sourceware.org References: <20060507220145.GA19231@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i 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/msg00074.txt.bz2 On Mon, May 08, 2006 at 12:50:03AM +0200, Bjarke Viksoe wrote: > Right. When I was testing all this I ran into more trouble. I would > actually see something like this: > > (gdb) -var-evaluate-expression A > ^done,value="12-var-evaluate-expression A > 34" > (gdb) > ^done,value="1234" > > ...because of the lack of flow-control in the telnet/SSH session (notice > how the next command is embedded in the output of the first). Well, that's a whole different problem. Note that GDB is _not_ echoing your commands here - it only handles output in MI mode. The terminal is doing it. On Unix systems, you can solve this by running "stty -echo" (beware, some shells reset this when in interactive mode - my zsh was eating it, I had to try in bash). > This put me back to square#1 since there was now no 1:1 relationship > between cmd/answ. While I agree that your plan is workable, I just > concluded that keeping track of a command-list wasn't a reliable > option without some severe pain when recovery was needed (aka back to > the option) - and I didn't feel that I was getting any closer > to having a state-less component. How would changing the MI output improve this situation at all? I can't see it. -- Daniel Jacobowitz CodeSourcery