From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4416 invoked by alias); 30 Nov 2005 13:59:30 -0000 Received: (qmail 4409 invoked by uid 22791); 30 Nov 2005 13:59:30 -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; Wed, 30 Nov 2005 13:59:28 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EhSUU-0004U2-Hq; Wed, 30 Nov 2005 08:59:22 -0500 Date: Wed, 30 Nov 2005 19:55:00 -0000 From: Daniel Jacobowitz To: Denis PILAT , Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Target stderr not displayed thru MI Message-ID: <20051130135921.GA17208@nevyn.them.org> Mail-Followup-To: Denis PILAT , Nick Roberts , gdb-patches@sources.redhat.com References: <17293.36697.854192.691800@kahikatea.snap.net.nz> <438DA1DE.2020406@st.com> <20051130135044.GA28404@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051130135044.GA28404@white> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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-11/txt/msg00511.txt.bz2 On Wed, Nov 30, 2005 at 08:50:44AM -0500, Bob Rossi wrote: > On Wed, Nov 30, 2005 at 01:58:06PM +0100, Denis PILAT wrote: > > > > Nick Roberts wrote: > > > > >>+ /* Route target error through the MI as well. */ > > >>+ gdb_stdtargerr = mi->targ; > > >> > > >> > > > > > >I know nothing about remote debugging but shouldn't error output go to > > >mi->err so that you can distinguish it from target output? > > > > > > > > > > > Nick, > > > > The mi->err is used for displaying debugger errors, not the error coming > > from the target execution. > > The main problem with MI is that we can not distinguish target stdout > > from target stderr. > > Hmm, that's interesting. Are you using the -inferior-tty-set option? > > A program can write to stdout (1), stderr (2), but it can > also write to any other file descriptor it wants to. I understand > solving the stdout/stderr case would be helpful, but would it be good to > think of it in terms of file descriptor number? For instance, a program > could easily open another file descriptor and point it to the > controlling terminal and write data. Is this case relavent? I assume that Denis is talking about a remote target here, providing I/O via their target protocol, rather than a native TTY. -- Daniel Jacobowitz CodeSourcery, LLC