From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2127 invoked by alias); 30 Nov 2005 13:51:08 -0000 Received: (qmail 2120 invoked by uid 22791); 30 Nov 2005 13:51:08 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao01.cox.net (HELO eastrmmtao01.cox.net) (68.230.240.38) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Nov 2005 13:51:06 +0000 Received: from white ([68.9.65.164]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051130135001.GRMY21607.eastrmmtao01.cox.net@white>; Wed, 30 Nov 2005 08:50:01 -0500 Received: from bob by white with local (Exim 3.36 #1 (Debian)) id 1EhSM8-0007OR-00; Wed, 30 Nov 2005 08:50:44 -0500 Date: Wed, 30 Nov 2005 19:03:00 -0000 From: Bob Rossi To: Denis PILAT Cc: Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Target stderr not displayed thru MI Message-ID: <20051130135044.GA28404@white> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438DA1DE.2020406@st.com> User-Agent: Mutt/1.5.9i 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/msg00510.txt.bz2 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? Thanks, Bob Rossi