From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3673 invoked by alias); 9 Oct 2005 20:02:53 -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 3653 invoked by uid 22791); 9 Oct 2005 20:02:51 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 09 Oct 2005 20:02:51 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EOhNg-0001vn-PM; Sun, 09 Oct 2005 16:02:48 -0400 Date: Sun, 09 Oct 2005 20:02:00 -0000 From: Daniel Jacobowitz To: "jingzhao.ou" , gdb@sources.redhat.com Subject: Re: Separating "shell dir" output from GDB/MI output Message-ID: <20051009200248.GA7166@nevyn.them.org> Mail-Followup-To: "jingzhao.ou" , gdb@sources.redhat.com References: <20051009123326.GA436@white> <20051009171225.GA4295@nevyn.them.org> <20051009173320.GA972@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051009173320.GA972@white> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00055.txt.bz2 On Sun, Oct 09, 2005 at 01:33:20PM -0400, Bob Rossi wrote: > > > 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=mi -mi-out-fd=30 > > > > 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. > > > > While I think this is a good idea, what other specific problems would > > it solve that we haven't solved already? > > It solves several problems. The user no longer has to create a pty to > give to GDB to separate the inferior output and the console output. > (CGDB will have to anyways, since it uses the terminal). This one we've already solved, albeit with a bit of extra work on the part of the frontend (and we were all enthusiastic about the solution, too...) > Some of the > target's apparently write to STDOUT/STDERR, and that get's confused with > the MI output. I don't know what you're referring to here. > Also, thing's like 'shell' and potentially other case's > get mixed in with the MI output. Shell's the only one I can think of offhand. > Finally, if we have several > interpreters going at the same time, we could have them all output to > there own descriptor. This is an interesting idea, but I don't think it's an obviously right choice. The CLI frontend wants its own terminal, really. The MI interpreter only needs a pipe. I have use for multiple MI interpreters running at the same time, which will all need their own pipes, but that's not a big deal with the infrastructure we already have. I think wrapping shell's output in MI quoting would be a simpler solution rather than changing the nature of MI/frontend interaction again. -- Daniel Jacobowitz CodeSourcery, LLC