From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28444 invoked by alias); 1 Dec 2005 20:14:23 -0000 Received: (qmail 28436 invoked by uid 22791); 1 Dec 2005 20:14:22 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 Dec 2005 20:14:16 +0000 Received: from kahikatea.snap.net.nz (p8-tnt1.snap.net.nz [202.124.110.8]) by viper.snap.net.nz (Postfix) with ESMTP id 3D3CC73180C; Fri, 2 Dec 2005 09:14:11 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id F2F948420; Fri, 2 Dec 2005 09:13:59 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17295.22919.290876.649298@kahikatea.snap.net.nz> Date: Thu, 01 Dec 2005 22:49:00 -0000 To: Daniel Jacobowitz Cc: Denis PILAT , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Target stderr not displayed thru MI In-Reply-To: <20051201143218.GB13069@nevyn.them.org> References: <17293.36697.854192.691800@kahikatea.snap.net.nz> <438DA1DE.2020406@st.com> <17294.2894.345752.773239@kahikatea.snap.net.nz> <438F011F.7050403@st.com> <20051201140436.GA31759@white> <20051201143218.GB13069@nevyn.them.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00025.txt.bz2 > Nick, what's your reasoning for separating this from the stdout data? > When we put the inferior onto its own TTY, we don't get stdout and > stderr separated, either. I was just trying to interpret what Denis said: DP> The main problem with MI is that we can not distinguish target stdout DP> from target stderr. I don't see any harm as, in the remote case, it presumably just prepends parts of a single stream with a different character. This would be easy to merge back if it wasn't needed. More recently, he has said that one stream is enough for his purposes: DP> I'm not sticked to have one more MI stream today since nobody DP> will use it efficiently, I just need to have at least target error DP> reported to a stream, even if it's the only mi stream available (mi->targ). Since no-one else appears to need another MI stream, or possibly even use MI for remote debugging, if we accept that adding a stream later may present compatibility problems, his original patch seems appropriate. Nick