From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22755 invoked by alias); 22 Jul 2002 20:11:17 -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 22661 invoked from network); 22 Jul 2002 20:11:15 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 22 Jul 2002 20:11:15 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 80B543CEB; Mon, 22 Jul 2002 16:11:15 -0400 (EDT) Message-ID: <3D3C66E3.50807@ges.redhat.com> Date: Mon, 22 Jul 2002 13:11:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020708 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, insight@sources.redhat.com Subject: Re: RFA: Make cli-out follow gdb_stdout 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-q3/txt/msg00031.txt.bz2 [...] > 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. enjoy, Andrew