From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16871 invoked by alias); 9 Oct 2005 20:19:45 -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 16863 invoked by uid 22791); 9 Oct 2005 20:19:42 -0000 Received: from eastrmmtao04.cox.net (HELO eastrmmtao04.cox.net) (68.230.240.35) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 09 Oct 2005 20:19:42 +0000 Received: from white ([68.9.64.121]) by eastrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051009201917.EJNU23022.eastrmmtao04.cox.net@white>; Sun, 9 Oct 2005 16:19:17 -0400 Received: from bob by white with local (Exim 3.36 #1 (Debian)) id 1EOhdj-0000U8-00; Sun, 09 Oct 2005 16:19:23 -0400 Date: Sun, 09 Oct 2005 20:19:00 -0000 From: Bob Rossi To: "jingzhao.ou" , gdb@sources.redhat.com Subject: Re: Separating "shell dir" output from GDB/MI output Message-ID: <20051009201923.GB972@white> Mail-Followup-To: "jingzhao.ou" , gdb@sources.redhat.com References: <20051009123326.GA436@white> <20051009171225.GA4295@nevyn.them.org> <20051009173320.GA972@white> <20051009200248.GA7166@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051009200248.GA7166@nevyn.them.org> User-Agent: Mutt/1.5.9i X-SW-Source: 2005-10/txt/msg00057.txt.bz2 On Sun, Oct 09, 2005 at 04:02:48PM -0400, Daniel Jacobowitz wrote: > 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...) Sorry, I honestly can't remember what your talking about. What was the solution for this that the front end had to do? Also, don't forget, on windows nativly, the front end *can't* open a PTY. Eli came up with this solution for that problem, http://sources.redhat.com/ml/gdb-patches/2005-08/msg00047.html > > 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. Oops, sorry. This is in the manual, and apparently is not true, target-stream-output is the output produced by the target program. All the target output is prefixed by `@'. We've had complaints by users that target output is not prefixed with '@'. So, I believe the output from the target can be intermingled with the MI output. > > 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. Yeah, me too. Darn shell command always break's front ends :( > > 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. This is interesting. How would you start up GDB in such a scenario? Say you wanted 2 MI interpreters running. What would you do? > I think wrapping shell's output in MI quoting would be a simpler > solution rather than changing the nature of MI/frontend interaction > again. Yeah, you sound correct on this point. Bob Rossi