From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5548 invoked by alias); 1 Dec 2005 13:57:39 -0000 Received: (qmail 5541 invoked by uid 22791); 1 Dec 2005 13:57:39 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-04.spheriq.net (HELO fra-del-04.spheriq.net) (195.46.51.100) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 Dec 2005 13:57:32 +0000 Received: from fra-out-02.spheriq.net (fra-out-02.spheriq.net [195.46.51.130]) by fra-del-04.spheriq.net with ESMTP id jB1DvA8C004271 for ; Thu, 1 Dec 2005 13:57:10 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-02.spheriq.net with ESMTP id jB1Dv5cY019312 for ; Thu, 1 Dec 2005 13:57:08 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id jB1Dv2FY001058 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 1 Dec 2005 13:57:05 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A5D7FDA4A; Thu, 1 Dec 2005 13:56:52 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id E21BB473CA; Thu, 1 Dec 2005 13:59:57 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3FC39759B0; Thu, 1 Dec 2005 13:59:57 +0000 (UTC) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 614EA473CA; Thu, 1 Dec 2005 13:59:55 +0000 (GMT) Received: from st.com (crx1177.cro.st.com [164.129.47.77]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CGC92255 (AUTH "denis pilat"); Thu, 1 Dec 2005 14:56:47 +0100 (CET) Message-ID: <438F011F.7050403@st.com> Date: Thu, 01 Dec 2005 13:57:00 -0000 From: Denis PILAT User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 MIME-Version: 1.0 To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Target stderr not displayed thru MI References: <17293.36697.854192.691800@kahikatea.snap.net.nz> <438DA1DE.2020406@st.com> <17294.2894.345752.773239@kahikatea.snap.net.nz> Content-Type: multipart/mixed; boundary="------------030603030207070705090806" X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.0 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-12/txt/msg00011.txt.bz2 This is a multi-part message in MIME format. --------------030603030207070705090806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1152 Nick Roberts wrote: > > > 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. > >In that case, can you create a new MI channel? e.g. > > > I'm not sure creating a new mi stream is on fashion, but I'm not opposed to that. My original problem was the following: > When debugging a program thru Eclipse or any front end using MI, > the stderr of the debugged program is lost. > This problem occures only on remote targets since native ones don't > use MI stream for output. Your solution won't fix my problem since current Eclipse uses MI 1 and will never recognize the new prefix. What we can do is creating a new error stream mi->targerr but with a prefix that will be: - the same than the mi->targ for MI 1 and 2, means "@" - a new one like you proposed for MI versoin > 2: "#" for instance. I attach a new patch in that sense. It does not include the documentation patch about MI new stream but it's just to give you an idea. Any comment ? Denis --------------030603030207070705090806 Content-Type: text/plain; name="mi-interp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mi-interp.patch" Content-length: 1481 2005-12-01 Denis Pilat * mi-interp.c (mi_interpreter_resume): Route target error through the MI. (struct mi_interp): Add field targerr. (mi_interpreter_init): Initialize mi target error stream. Index: mi/mi-interp.c =================================================================== --- mi/mi-interp.c (revision 224) +++ mi/mi-interp.c (working copy) @@ -40,6 +40,7 @@ struct ui_file *err; struct ui_file *log; struct ui_file *targ; + struct ui_file *targerr; struct ui_file *event_channel; /* This is the interpreter for the mi... */ @@ -86,6 +87,15 @@ mi->err = mi_console_file_new (raw_stdout, "&", '"'); mi->log = mi->err; mi->targ = mi_console_file_new (raw_stdout, "@", '"'); + + /* MI 1 and 2 target error stream use the same steam prefix "@" in oder + to ensure backward compatibility with old frondtend, MI 3 uses + a new prefix "#" */ + if (mi_version (uiout) > 2) + mi->targerr = mi_console_file_new (raw_stdout, "#", '"'); + else + mi->targerr = mi_console_file_new (raw_stdout, "@", '"'); + mi->event_channel = mi_console_file_new (raw_stdout, "=", 0); return mi; @@ -119,6 +129,8 @@ gdb_stdlog = mi->log; /* Route target output through the MI. */ gdb_stdtarg = mi->targ; + /* Route target error through the MI error stream. */ + gdb_stdtargerr = mi->targerr; /* Replace all the hooks that we know about. There really needs to be a better way of doing this... */ --------------030603030207070705090806--