From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30750 invoked by alias); 23 Jul 2002 16:45:59 -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 30743 invoked from network); 23 Jul 2002 16:45:57 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 23 Jul 2002 16:45:57 -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 17X2nO-0002ft-00 for ; Tue, 23 Jul 2002 11:45:58 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17X2nS-00070e-00 for ; Tue, 23 Jul 2002 12:46:02 -0400 Date: Tue, 23 Jul 2002 09:45:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Overriding uiout Message-ID: <20020723164601.GA23869@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2002-07/txt/msg00238.txt.bz2 There are currently only four code paths in the entire GDB source tree where uiout could theoretically be overridden to something other than the normal uiout. They're all for libgdb: gdb_value_struct_elt, gdb_thread_select, gdb_list_thread_ids, and gdb_breakpoint_query. The only place it actually appears to be overridden is in gdb_value_struct_elt, which is occasionally called from varobj code with uiout==NULL. Otherwise it is always overridden to itself. This overriding mechanism makes it a bit awkward to redirect GDB's output; any change to uiout is lost after the current command if we are running from the prompt (although, surprisingly and IMO inconsistently, it lasts until the end of a user-defined function). So I'll ask again - what is this interface supposed to accomplish? If it's just a step down the road to passing explicit state everywhere, then I think it's a significant step backwards in other ways, and that we should instead let clients or wrapper functions manipulate the global state until we're truly ready to pass a global state around - a global state which can be overridden for this sort of task. This is purely a design question, not an implementation objection. For implementation I'm restricting this feature to CLI only, and implementing it within cli-out. It turned out to be more elegant than I expected. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer