From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20005 invoked by alias); 29 Nov 2005 14:08:18 -0000 Received: (qmail 19998 invoked by uid 22791); 29 Nov 2005 14:08:17 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-03.spheriq.net (HELO lon-del-03.spheriq.net) (195.46.50.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Nov 2005 14:08:14 +0000 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-03.spheriq.net with ESMTP id jATE8BMR015320 for ; Tue, 29 Nov 2005 14:08:11 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-02.spheriq.net with ESMTP id jATE8ATc008235 for ; Tue, 29 Nov 2005 14:08:10 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id jATE86Rp018613 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 29 Nov 2005 14:08:09 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 77B4CDA49 for ; Tue, 29 Nov 2005 14:07:50 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 370F34743E; Tue, 29 Nov 2005 14:10:43 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id EFCA675994 for ; Tue, 29 Nov 2005 14:10:42 +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 ABE4F47454 for ; Tue, 29 Nov 2005 14:10:41 +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 CGC44283 (AUTH "denis pilat"); Tue, 29 Nov 2005 15:07:33 +0100 (CET) Message-ID: <438C60A3.4050904@st.com> Date: Wed, 30 Nov 2005 02:47: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: gdb-patches@sources.redhat.com Cc: Serge CHATROUX Subject: [PATCH] Target stderr not displayed thru MI Content-Type: multipart/mixed; boundary="------------000703000708060901000002" 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-11/txt/msg00501.txt.bz2 This is a multi-part message in MIME format. --------------000703000708060901000002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 523 Hi all, 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. In the file gdb/mi/mi-interp.c, the 'mi_interpreter_resume' function redirects the gdb stream into MI streams. All streams are redirected except gdb_stdtargerr. The attached patch (from a ST colleague) redirects target error output on the unique MI target output stream. Do you have any comment ? Denis --------------000703000708060901000002 Content-Type: text/plain; name="mi-interp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mi-interp.patch" Content-length: 594 2005-11-20 Serge Chatroux * mi-interp.c (mi_interpreter_resume): Route target error through the MI. Index: mi-interp.c =================================================================== --- mi-interp.c (revision 245) +++ mi-interp.c (working copy) @@ -119,6 +119,8 @@ gdb_stdlog = mi->log; /* Route target output through the MI. */ gdb_stdtarg = mi->targ; + /* Route target error through the MI as well. */ + gdb_stdtargerr = mi->targ; /* Replace all the hooks that we know about. There really needs to be a better way of doing this... */ --------------000703000708060901000002--