From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6576 invoked by alias); 2 Aug 2005 20:46:26 -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 6058 invoked by uid 22791); 2 Aug 2005 20:46:08 -0000 Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 02 Aug 2005 20:46:08 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-203-254.inter.net.il [80.230.203.254]) by nitzan.inter.net.il (MOS 3.6.5-GR) with ESMTP id BAR09933 (AUTH halo1); Tue, 2 Aug 2005 23:45:22 +0300 (IDT) Date: Tue, 02 Aug 2005 20:46:00 -0000 Message-Id: From: Eli Zaretskii To: gdb-patches@sources.redhat.com In-reply-to: <20050802035020.GA18143@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 1 Aug 2005 23:50:20 -0400) Subject: Re: MI testsuite to use PTY for inferior Reply-to: Eli Zaretskii References: <20050731131653.GC22547@white> <20050731153051.GA28158@nevyn.them.org> <20050731212021.GA24144@white> <20050801113002.GB24853@white> <200508011901.j71J1i1w026583@elgar.sibelius.xs4all.nl> <20050801205242.GA20064@nevyn.them.org> <20050802035020.GA18143@nevyn.them.org> X-SW-Source: 2005-08/txt/msg00047.txt.bz2 > 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.