From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28374 invoked by alias); 13 Aug 2005 16:55:24 -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 28353 invoked by uid 22791); 13 Aug 2005 16:55:20 -0000 Received: from centrmmtao06vip.cox.net (HELO centrmmtao06.cox.net) (68.1.16.144) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 13 Aug 2005 16:55:20 +0000 Received: from white ([68.9.64.121]) by centrmmtao06.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050813165518.EGYV1571.centrmmtao06.cox.net@white> for ; Sat, 13 Aug 2005 12:55:18 -0400 Received: from bob by white with local (Exim 3.36 #1 (Debian)) id 1E3zHy-00009T-00 for ; Sat, 13 Aug 2005 12:55:18 -0400 Date: Sat, 13 Aug 2005 17:26:00 -0000 From: Bob Rossi To: gdb-patches@sources.redhat.com Subject: Re: MI testsuite to use PTY for inferior Message-ID: <20050813165518.GA568@white> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20050801113002.GB24853@white> <200508011901.j71J1i1w026583@elgar.sibelius.xs4all.nl> <20050801205242.GA20064@nevyn.them.org> <20050802035020.GA18143@nevyn.them.org> <20050802204750.GA14919@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802204750.GA14919@nevyn.them.org> User-Agent: Mutt/1.5.9i X-SW-Source: 2005-08/txt/msg00160.txt.bz2 On Tue, Aug 02, 2005 at 04:47:50PM -0400, Daniel Jacobowitz wrote: > On Tue, Aug 02, 2005 at 11:45:20PM +0300, Eli Zaretskii wrote: > > > Date: Mon, 1 Aug 2005 23:50:20 -0400 > > > From: Daniel Jacobowitz > > > Cc: gdb-patches@sources.redhat.com > > > > > > Yes, but the problem's that the buffering is in the program being > > > debugged. It's not the buffering of the GDB MI stream that's the > > > problem, but the fact that the stdout of the program you're debugging > > > would suddenly become block buffered instead of line buffered, if you > > > fed it to a pipe when it expects a TTY. > > > > This started as a discussion how to separate MI output from the > > debuggee's. For that, I suggested to redirect MI's output (_not_ the > > debuggee's) to a different file handle. That should not change the > > buffering of the debuggee's stdout in any way. While the problem you > > mention is real, it has nothing to do with separation of these two > > streams: if sending the program's output to a pipe changes its > > buffering, we already have that annoyance on Windows. > > Ah! Thank you, I misunderstood your solution. This is a very > interesting idea indeed. This is a good solution. I just had yet another idea, that might be worth while. It would be a simple way to allow the FE to separate the MI output command and the inferior output data. Currently, GDB works like this, (gdb) -interpreter-exec console "b test.c:49" ~"Breakpoint 1 at 0x8048525: file test.c, line 49.\n" ^done (gdb) -interpreter-exec console "r" ~"Starting program: /home/bob/cvs/cgdb/cgdb.readline/objdir/test \n" OUTPUT FROM INFERIOR ~"\n" ~"Breakpoint 1, main (argc=1, argv=0xbffffb54) at test.c:49\n" ~"49\t for ( i = 0; i < 100; i++)\n" ^done (gdb) If we let GDB do what it does know, except change the MI output command to allow something like, (gdb) -interpreter-exec console "b test.c:49" ~"Breakpoint 1 at 0x8048525: file test.c, line 49.\n" ^done (gdb) -interpreter-exec console "r" ~"Starting program: /home/bob/cvs/cgdb/cgdb.readline/objdir/test \n" =inferior-starting unique-key OUTPUT FROM INFERIOR =inferior-stopped unique-key ~"\n" ~"Breakpoint 1, main (argc=1, argv=0xbffffb54) at test.c:49\n" ~"49\t for ( i = 0; i < 100; i++)\n" ^done (gdb) In this way, the FE can still break the output into lines, and it can strcmp the line to determine if the output is from GDB or the inferior. The "unique-key" takes care of the case where you are actually debugging GDB, because once the FE get's the '=inferior-starting unique-key' line, it doesn't care how many =inferior-started or =inferior-stopped lines get sent out until the key matches. This sounds like a very simple solution. What does everyone think? Thanks, Bob Rossi