From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30734 invoked by alias); 22 Jul 2002 20:18:01 -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 30698 invoked from network); 22 Jul 2002 20:17:58 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 22 Jul 2002 20:17:59 -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 17Wjd0-0001OV-00; Mon, 22 Jul 2002 15:17:58 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17Wjd1-0002i8-00; Mon, 22 Jul 2002 16:17:59 -0400 Date: Mon, 22 Jul 2002 13:18: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: <20020722201759.GA10223@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> <20020722194126.GA8756@nevyn.them.org> <3D3C66E3.50807@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D3C66E3.50807@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-q3/txt/msg00032.txt.bz2 On Mon, Jul 22, 2002 at 04:11:15PM -0400, Andrew Cagney wrote: > > [...] > > >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. > > As they say, I don't yet know. I think it is pretty clear that the I/O > is just one part of this state problem. Since of thread, frame, > register cache, ... are heavily dependant on state implemented with > globals a guess is an object (or object relationship) that contains that > state. In the mean time we need to ensure that we're not entrenching > the problem (eg by adding another bit of code assuming global state). > > For the immediate problem, the intent is for catch_exceptions() to be > used when overriding gdb's I/O. Given, looking at the code, it too > fails to keep that assertion (oops): > > > global uiout->stream->ui_file == global gdb_stdout > > I think the thing to do is fix catch-exceptions and then use that. catch_exceptions is for executing a particular command. These commands redirect the output of multiple commands; possibly an entire session. catch_exceptions isn't built for that sort of use. The only way that I could see to fix catch_exceptions in this regard would involve some way to get gdb_stdout etc. from the uiout object. In that case I'm just going to restrict my commands to CLI only, and do: uiout = cli_out_new (new_gdb_stdout) in the function. Patch withdrawn until we figure out a better model here. I bet you aren't going to like my introduction of another wrapper much either... but I fail to see an option. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer