From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10517 invoked by alias); 9 Oct 2005 17:04:41 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10508 invoked by uid 22791); 9 Oct 2005 17:04:38 -0000 Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.197) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 09 Oct 2005 17:04:38 +0000 Received: by xproxy.gmail.com with SMTP id h27so768755wxd for ; Sun, 09 Oct 2005 10:04:36 -0700 (PDT) Received: by 10.70.43.15 with SMTP id q15mr1579599wxq; Sun, 09 Oct 2005 10:04:36 -0700 (PDT) Received: by 10.70.80.3 with HTTP; Sun, 9 Oct 2005 10:04:36 -0700 (PDT) Message-ID: Date: Sun, 09 Oct 2005 17:04:00 -0000 From: "jingzhao.ou" To: "jingzhao.ou" , gdb@sources.redhat.com Subject: Re: Separating "shell dir" output from GDB/MI output In-Reply-To: <20051009123326.GA436@white> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051009123326.GA436@white> X-SW-Source: 2005-10/txt/msg00051.txt.bz2 Thanks a lot for the reply. I really like your idea if it can be supported on both Windows and Linux platforms. I have another problem with MI. I want to provide a GDB console in my application so that the user can work with GDB directly if needed. However, if I enable the MI interpreter, the normal GDB output is suppressed. I hope that two interpreters can work at the same time and their outputs are directed to two different output file descriptors. This would give me exactly what I want and all I need. :-) Again, thanks! Best regards, Jingzhao On 10/9/05, Bob Rossi wrote: > I think the best idea we've had so far for solving problems like this is > to add an option to GDB to have it output GDB/MI data on a file > descriptor X. For instance, > gdb -i=3Dmi -mi-out-fd=3D30 > and then when you fork/exec GDB you dup the 30 file descriptor so that > you can read the output. > > Eli, do you know if this approach would be portable to windows nativly? > I could look into implementing this feature, since it would resolve a > *lot* of problems regarding I/O. > > Thanks, > Bob Rossi >