From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25459 invoked by alias); 22 Jul 2002 19:41:26 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 25405 invoked from network); 22 Jul 2002 19:41:24 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 22 Jul 2002 19:41:24 -0000 Received: from dsl254-114-118.nyc1.dsl.speakeasy.net ([216.254.114.118] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17Wj3c-0001LO-00; Mon, 22 Jul 2002 14:41:24 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17Wj3e-0002JW-00; Mon, 22 Jul 2002 15:41:26 -0400 Date: Mon, 22 Jul 2002 12:41:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com, insight@sources.redhat.com Subject: Re: RFA: Make cli-out follow gdb_stdout Message-ID: <20020722194126.GA8756@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com, insight@sources.redhat.com References: <20020717183012.GA9788@nevyn.them.org> <3D3C4AFF.2090003@ges.redhat.com> <20020722182149.GA5211@nevyn.them.org> <3D3C5A9D.2010409@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D3C5A9D.2010409@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-q3/txt/msg00030.txt.bz2 On Mon, Jul 22, 2002 at 03:18:53PM -0400, Andrew Cagney wrote: > > >I'm not thrilled with it myself. Let me explain what I'm trying to do, > >and let's see if we can come up with a better model. > > > >I have a function which temporarily redirects GDB's output. How does > >it do this? Well, the best way seems to be to modify > >gdb_std{out,err,log}. But the old value of gdb_stdout is cached in the > >cli_out object. > > So the assertion: > > global uiout->stream->ui_file == global gdb_stdout > > doesn't hold :-( > > >The two minimal solutions were the one above (using a ui_file**) or > >hardcoding gdb_stdout (since that's the only thing it's ever used for > >at present). They're both a bit of a step backwards. I could provide > >methods to query and set the underlying stream of a ui_out object, but > >the differences between the different ui_out objects make that a little > >awkward. Would that be better? > > Both of those are still wrong. The global gdb_stdout should be going > away replaced with some sort of explicitly parameterized i/o object. > That is why catch_exceptions() takes a ui_out. Well, that's not helpful in the short term :P What do you envision by explicitly parametrized i/o object? I really don't think that's a good idea. It would have to be passed down all the way to every target function which might want to print some kind of output. That's a lot of bulk for no visible gain; somewhere down the road if we supported multiple instantiations of the gdb library, maybe, but we're so far away from that that this sort of direction seems futile, until we are at least passing an object cookie everywhere. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer